On 2020/11/10 上午1:44, David Sterba wrote:
> On Tue, Nov 03, 2020 at 09:31:03PM +0800, Qu Wenruo wrote:
>> There are several factors affecting how many checksum bytes are needed
>> for one scrub_page:
>>
>> - Sector size and page size
>>   For subpage case, one page can contain several sectors, thus the csum
>>   size will differ.
>>
>> - Checksum size
>>   Since btrfs supports different csum size now, which can vary from 4
>>   bytes for CRC32 to 32 bytes for SHA256.
>>
>> So instead of using fixed BTRFS_CSUM_SIZE, now use flexible array for
>> scrub_page::csums, and determine the size at scrub_page allocation time.
>>
>> This does not only provide the basis for later subpage scrub support,
> 
> I'd like to know more how this would help for the subpage support.

For the future, if we utilize the full page for scrub (other than
current only use sector size of the page content), we could benefit from
the flexible array.

E.g. 4K sector size, 64K page size, SHA256 csum.
For one full 64K page, it can contain 16 sectors, and each sector need
full 32 bytes for csum.
Making it to 512 bytes, which is definitely not supported by current code.

But that's in the future, as current subpage scrub still uses at most
BTRFS_CSUM_SIZE for each scrub_page.

> 
>> but also reduce the memory usage for default btrfs on x86_64.
>> As the default CRC32 only uses 4 bytes, thus we can save 28 bytes for
>> each scrub page.
> 
> Because even with the flexible array, the allocation is from the generic
> slabs and scrub_page is now 128 bytes, so saving 28 bytes won't make any
> difference.
> 
OK, I could discard the patch for now.

Thanks,
Qu