Re: What is the vision for btrfs fs repair?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

On 2014-10-09 07:53, Duncan wrote:
> Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
> excerpted:
>
>> Also, you should be running btrfs scrub regularly to correct bit-rot
>> and force remapping of blocks with read errors.  While BTRFS
>> technically handles both transparently on reads, it only corrects thing
>> on disk when you do a scrub.
>
> AFAIK that isn't quite correct.  Currently, the number of copies is
> limited to two, meaning if one of the two is bad, there's a 50% chance of
> btrfs reading the good one on first try.
>
> If btrfs reads the good copy, it simply uses it.  If btrfs reads the bad
> one, it checks the other one and assuming it's good, replaces the bad one
> with the good one both for the read (which otherwise errors out), and by
> overwriting the bad one.
>
> But here's the rub.  The chances of detecting that bad block are
> relatively low in most cases.  First, the system must try reading it for
> some reason, but even then, chances are 50% it'll pick the good one and
> won't even notice the bad one.
>
> Thus, while btrfs may randomly bump into a bad block and rewrite it with
> the good copy, scrub is the only way to systematically detect and (if
> there's a good copy) fix these checksum errors.  It's not that btrfs
> doesn't do it if it finds them, it's that the chances of finding them are
> relatively low, unless you do a scrub, which systematically checks the
> entire filesystem (well, other than files marked nocsum, or nocow, which
> implies nocsum, or files written when mounted with nodatacow or
> nodatasum).
>
> At least that's the way it /should/ work.  I guess it's possible that
> btrfs isn't doing those routine "bump-into-it-and-fix-it" fixes yet, but
> if so, that's the first /I/ remember reading of it.

I'm not 100% certain, but I believe it doesn't actually fix things on 
disk when it detects an error during a read, I know it doesn't it the fs 
is mounted ro (even if the media is writable), because I did some 
testing to see how 'read-only' mounting a btrfs filesystem really is.

Also, that's a much better description of how multiple copies work than 
I could probably have ever given.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]