Re: [PATCH v2 4/7] btrfs: introduce new read-repair infrastructure

Qu Wenruo
2022-05-26T08:08:05Z

On 2022/5/26 16:00, Christoph Hellwig wrote:
> On Thu, May 26, 2022 at 03:52:03PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2022/5/26 15:45, Christoph Hellwig wrote:
>>> On Thu, May 26, 2022 at 03:37:47PM +0800, Qu Wenruo wrote:
>>>> Rare case doesn't mean it won't happen.
>>>>
>>>> We still need to address it anyway.
>>>
>>> address != build overly complicated code to optimize for it
>>>
>> Well, using seemly simple code, but can lead to read way more loops and way
>> more data to read, is neither a good way.
>
> Again, having checkered corruption is an extremely unlikely event.
> I'd rather deal with it by doing more reads than code complexity.
>

Then it can be said to almost all ENOSPC error handling code.
It's less than 1% chance, but we spend over 10% code for it.

And if you really want to go that path, I see no reason why we didn't go
sector-by-sector repair.

Furthermore if "more reads" means over 10 times the amount we need, I
strongly doubt if it's sane.

Just the same RAID1C3, mirror 1 all corrupted, mirror 2 and 3 checker
pattern, fill it into a 4MiB range, and try run your version of code
starting with mirror 1, and see how many loops we need to go, especially
how many times we need to read mirror 1 unnecessarily.

Thanks,
Qu