On Tue, May 5, 2015 at 8:21 AM, Neil Bothwick <[email protected]> wrote: > On Tue, 5 May 2015 13:05:55 +0100, Mick wrote: > >> During a backup of a home directory I noticed loads of Chromium and >> Firefox crash/recovery files being copied over. However, I don't know >> if this is a btrfs problem, or the fact that I had to forcefully shut >> down KDE once or twice recently, because the desktop would not >> logout/shutdown normally. > > Chromium saves its open tabs and reopens them after a reboot, even if it > is shut down forcibly. > >> The fsck which ran when the machine rebooted did not revealed any >> problems. Is there a different recommended way for checking for fs >> errors? > > btrfs check - it needs the filesystem to be unmounted and has a repair > option.
I don't think the chromium/firefox issues are in any way a sign of a filesystem problem. Application crashing and filesystem errors are completely different matters. If atop dumps core 14 times a day (as it seems to love to do) btrfs just happily stores them in case I ever want to look at them. In general btrfs tends to do most of its fixing online. I'd only run btrfs check if the filesystem is unmountable. I wouldn't trust it not to do more harm than good. For a very long time it didn't even exist, and btrfs is a bit different from most other filesystems in this regard. btrfs doesn't complain if you mount it unclean - almost all the recovery code is in the kernel and it will generally tidy up as it goes. This is in contrast to many other filesystems that force you to run fsck if they were not cleanly unmounted. I'm not saying it is broken. I haven't really used it much. However, for the most part btrfs was designed around doing most of its operations online and these are probably the more mature code paths. That said, btrfs check without the --repair option should be read-only, so you can always try it. However, I wouldn't be surprised at all if there are no problems with your filesystem (assuming you run it after a clean shutdown). If there were any problems, btrfs should have cleaned them up on your last mount. btrfs does not overwrite data in-place in any case, so it is a bit like ext4 with data=journal in normal operation. And that is what I like about btrfs (and the same applies to zfs) - the basic design of the filesystem tends to prioritize data integrity, and thus even with all my panics and mounting problems with btrfs, I've always been able to recover, and at every point I could at least mount the filesystems read-only and read everything off of them. And a successful read on btrfs/zfs means that the checksum matched, so the risk of corruption is fairly low. -- Rich
