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