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

Qu Wenruo
2022-05-26T08:49:33Z

On 2022/5/26 16:28, Christoph Hellwig wrote:
> On Thu, May 26, 2022 at 04:26:30PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2022/5/26 16:17, Christoph Hellwig wrote:
>>> On Thu, May 26, 2022 at 04:07:49PM +0800, Qu Wenruo wrote:
>>>> Then it can be said to almost all ENOSPC error handling code.
>>>
>>> ENOSPC is a lot more common.
>>
>> Sorry, I mean ENOMEM.
>>
>>>
>>>> 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.
>>>
>>> Because that really sucks for the case where the whole I/O fails.
>>> Which is the common failure scenario.
>>
>> But it's just a performance problem, which is not that critical.
>
> I'm officially lost now.

Why? If you care so much about the code simplicity, sector-by-sector is
the best.
If you care so much about the performance, the latest bitmap is the
best, no matter if it's the worst checker patter or not.