Re: [PATCH 3/7] btrfs/137: Make this compatible with all block sizes

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2025/8/5 19:11, Ojaswin Mujoo 写道:
> On Mon, Aug 04, 2025 at 01:28:24PM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2025/7/29 15:51, Nirjhar Roy (IBM) 写道:
>>> For large blocksizes like 64k on powerpc with 64k pagesize
>>> it failed simply because this test was written with 4k
>>> block size in mind.
>>> The first few lines of the error logs are as follows:
>>>
>>>        d3dc847171f9081bd75d7a2d3b53d322  SCRATCH_MNT/snap2/bar
>>>
>>>        File snap1/foo fiemap results in the original filesystem:
>>>       -0: [0..7]: data
>>>       +0: [0..127]: data
>>>
>>>        File snap1/bar fiemap results in the original filesystem:
>>>       ...
>>>
>>> Fix this by making the test choose offsets based on
>>> the blocksize.
>>
>> I'm wondering, why not just use a fixed 64K block size?
> 
> Hi Qu,
> 
> It will definitely be simpler to just use 64k io size but I feel it
> might be better to not hard code it for future proofing the tests. I
> know right now we don't have bs > ps in btrfs but maybe we get it in the
> future and we might start seeing funky block sizes > 64k.

And in fact I'm going to add that bs > ps support very soon, since we 
already have large folio support for data, it will be just a simple 
mapping_set_folio_order_range() with a min order.

But still for btrfs, we're only going to support 4K, 8K, 16K, 32K, 64K 
block sizes, thus I don't think we need to bother larger bs yet.

Thanks,
Qu

> 
> Same goes for not hardcoding block mappings in the golden output.
> 
> Regards,
> ojaswin
> 
>