On Fri, Sep 18, 2015 at 2:19 PM, Mick <michaelkintz...@gmail.com> wrote: > On Friday 18 Sep 2015 19:15:50 Rich Freeman wrote: >> On Fri, Sep 18, 2015 at 1:56 PM, Mick <michaelkintz...@gmail.com> wrote: >> > On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote: >> >> On Friday 18 September 2015 10:31:01 Mick wrote: >> >> >A couple of months ago the akonadi DB went sideways and kmail played up >> >> >as a result. Again I was suspicious of btrfs, but neither the logs >> >> >nor fsck showed up anything. >> >> >> >> I take it "btrfs scrub" didn't turn up anything, or is that what you >> >> meant by fsck? >> > >> > Am I supposed to run scrub with I do not have a RAID running? I thought >> > scrub was meant for comparing checksums between mirrored fs - have I got >> > this wrong? >> >> You can actually run scrub on a non-raid btrfs setup. Btrfs will >> report any errors that it detects (using the checksumming in the >> filesystem), but it would not be able to fix errors unless you have it >> storing redundant data somewhere (even on non-raid it still stores >> redundant metadata by default, and you can choose to do this with data >> as well which protects against block-level failures but not disk-level >> failures, obviously). >> >> However, you'd have gotten the same errors in dmesg just trying to >> read the files - btrfs checks the checksum on all file read >> operations. That is a big part of the value of both btrfs and zfs. > > Ah! V interesting ... can I run scrub with mounted partitions, or do I have > to do it from a LiveCD?
I didn't check, but I suspect you can only run scrub on a mounted partition. I also suspect that fsck probably has an option to do something equivalent offline. You do get the error-detection anyway just by reading files, and if you just ran find on your filesystem and catted every file you have to /dev/null that would actually accomplish the same thing as long as you're not in a redundant mode (simply reading all the files doesn't guarantee that all copies of each file are checked). The main reason for doing a scrub is to detect latent issues, and if you have redundancy that means you can auto-correct them today, rather than discovering them a month from now when the drive containing the only good copy fails. Even if you don't have redundancy maybe you rotate your backups every 30 days and detecting the error might mean having the ability to go back and restore a good copy of the file before it is completely replaced with bad copies. -- Rich
