Re: What is the vision for btrfs fs repair?

[Austin S Hemmelgarn]

On 2014-10-09 08:12, Hugo Mills wrote:

On Thu, Oct 09, 2014 at 08:07:51AM -0400, Austin S Hemmelgarn wrote:

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'm fairly sure it does, as I've had it happen to me. :)

I probably just misinterpreted the source code, while I know enough C to generally understand things, I'm by far no expert.

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.

    If the FS is RO, then yes, it won't fix things.

    Hugo.

smime.p7s
Description: S/MIME Cryptographic Signature