| 1 |
On Sat, Mar 28, 2015 at 5:57 AM, Mick <michaelkintzios@×××××.com> wrote: |
| 2 |
> On Saturday 28 Mar 2015 02:53:28 Rich Freeman wrote: |
| 3 |
> |
| 4 |
>> What I haven't gotten to work lately is a crash kernel. With all my |
| 5 |
>> btrfs panics of late it would sure be handy for troubleshooting... |
| 6 |
> |
| 7 |
> I am using btrfs with 3.18.9-gentoo kernel and had no indication of fs |
| 8 |
> corruption yet. Should I be worried? What is it recommended that I check? |
| 9 |
> |
| 10 |
|
| 11 |
If you're casually running btrfs I'd advise having thought through |
| 12 |
what you'll do if the filesystem eats your data. That isn't bad |
| 13 |
advice for any setup, but your risks are going to be higher with btrfs |
| 14 |
than ext4. |
| 15 |
|
| 16 |
Other than that, I'd just stick with a relatively recent stable |
| 17 |
kernel, but I'd personally shy away from the most recent. Sticking |
| 18 |
with an LTS like 3.18 is probably best. But, it was 3.18.9 that |
| 19 |
refused to mount my root filesystem. :) Booting with 3.18.8 and |
| 20 |
running on that for a while seemed to solve the problem, but I did get |
| 21 |
a few panics over a day. I did a full balance which probably also |
| 22 |
helped. Root cause was never determined - I suspect that this |
| 23 |
probably wasn't a regressing in 3.18.9 so much as it being fussier |
| 24 |
about what it mounts. Over time they've been adding more |
| 25 |
error-checking to the btrfs code with the goal that they'd rather not |
| 26 |
touch a filesystem than work with data that looks bad. |
| 27 |
|
| 28 |
The most recent issue did actually corrupt a file - a chromium |
| 29 |
preferences file (I'm not actually sure it was corrupt - it may have |
| 30 |
just been moved to lost+found and visual inspection didn't show |
| 31 |
anything obviously wrong with it, but chromium settings are trivial to |
| 32 |
re-sync anyway). Before that I've never had an actual file corruption |
| 33 |
from btrfs - just refusal to mount a drive until it was cleaned up, or |
| 34 |
a kernel patch was applied. The other thing is that I've always been |
| 35 |
able to mount my btrfs filesystems read-only, which is obviously |
| 36 |
useful in a disaster scenario. |
| 37 |
|
| 38 |
But, I keep a daily rsnapshot backup of all my btrfs filesystems on |
| 39 |
ext4. Btrfs send would be far more efficient, but my whole point is |
| 40 |
to protect myself from btrfs failures so a dumb backup to ext4 covers |
| 41 |
me against any btrfs failure mode as long as it becomes visible within |
| 42 |
a few days (the limit of my retention schedule). |
| 43 |
|
| 44 |
-- |
| 45 |
Rich |
Archives