Re: [PATCH v5 0/2] btrfs: fix beyond EOF truncation for subpage generic/363 failures

[Qu Wenruo <wqu@suse.com>]

在 2025/5/6 01:03, David Sterba 写道:
> On Sat, Apr 26, 2025 at 08:06:48AM +0930, Qu Wenruo wrote:
>> [CHANGELOG]
>> v5:
>> - Shrink the parameter list for btrfs_truncate_block()
>>    Remove the @front and @len, instead passing a new pair of @start/@end,
>>    so that we can determine if @from is in the head or tail block,
>>    thus no need for @front.
>>
>>    This will give callers more freedom (a little too much),
>>    e.g. for the following zero range/hole punch case:
>>
>>      Page size is 64K, fs block size is 4K.
>>      Truncation range is [6K, 58K).
>>
>>      0        8K                32K                  56K      64K
>>      |      |/|//////////////////////////////////////|/|      |
>>             6K                                         58K
>>
>>      To truncate the first block to zero out range [6K, 8K),
>>      caller can pass @from = 6K, @start = 6K, @end = 58K - 1.
>>      In fact, any @from inside range [6K, 8K) will work.
>>
>>      To truncate the last block to zero out range [56K, 58K),
>>      caller can pass @from=58K - 1, @start = 6K, @end = 58K -1.
>>      Any @from inside range [56K, 58K) will also work.
>>
>>      Furthermore, if aligned @from is passed in, e.g. 8K,
>>      btrfs_truncate_block() will detect that there is nothing to do,
>>      and exit properly.
>>
>> - Only do the extra zeroing if we're truncating beyond EOF
>>    Especially for the recent large folios support, we can do a lot of
>>    unnecessary zeroing for a very large folio.
>>
>> - Remove the lock-wait-retry loop if we're doing aligned truncation
>>    beyond EOF
>>    Since it's already EOF, there is no need to wait for the OE anyway.
> 
> The patches have been in linux-next but I don't think they got coverage
> on the 64k/4k setups. If you don't have further updates please add the
> series to for-next. Thanks.

I'd prefer Boris to give it a final glance.

This v5 changes the parameter list, thus it is different from previous 
versions.

Although tests wise it's pretty boring on x86_64 and aarch64.

Thanks,
Qu