Re: What is the vision for btrfs fs repair?

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

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

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.
>



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