Re: [PATCH] btrfs: scrub: expand scrub block size for data range scrub

[Qu Wenruo <wqu@suse.com>]

On 2022/11/16 02:29, li zhang wrote:
> Qu Wenruo <quwenruo.btrfs@gmx.com> 于2022年11月15日周二 18:37写道：
>>
>> [Adding the mailing list, as the reply is to the first mail I got, which
>> lacks the ML]
>>
>> On 2022/11/15 06:39, Qu Wenruo wrote:
>> [...]
> 
>> I'll try to craft a PoC patchset to a stripe by stripe verification (to
>> get rid of the complex bio form shaping code), and a proper bitmap based
>> verification and repair (to only repair the corrupted sectors).
>>
>> But as I mentioned above, the bad csum error reporting can not be easily
>> fixed without a behavior change on btrfs_scrub_progress results.
>>
> 
> Actually, I also considered refactoring the functions
> scrub_recheck_block and scrub_recheck_block_checksum to import a
> bitmap to represent bad sectors, but this seems too complicated and
> may affect many things,

Another thing I don't like is the various jumps using different end_io 
functions.

I'm a super big fan of submit-and-wait, and already converted RAID56 to 
this way.
Thus I believe I can also handle the situation in scrub, and hopefully 
get it easier to read.

> so I choose
> Handle newly discovered errors by recheck in
> scrub_handle_errored_block, ignoring recheck errors by exchanging the
> result of the first check and the result of the recheck, as follows:
> else if (!check_sector->checksum_error && bad_sector->checksum_error) {
>   struct scrub_sector *temp_sector = sblock_bad->sectors[sector_num];
> 
>   sblock_bad->sectors[sector_num]
>   = sblock_to_check->sectors[sector_num];
> sblock_to_check->sectors[sector_num] = temp_sector;
> 
> Anyway, I'll take a hard look at your scrub_fs idea

Feel free to do any comments, I'm pretty eager to get some feedback on it.

Thanks,
Qu