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