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

Qu Wenruo
2025-08-05T09:45:00Z

在 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
>
>