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

Nirjhar Roy (IBM)
2025-08-12T06:23:20Z

On 8/5/25 16:17, Filipe Manana wrote:
> On Tue, Aug 5, 2025 at 10:41 AM Ojaswin Mujoo <ojaswin@linux.ibm.com> wrote:
>> 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.
>>
>> Same goes for not hardcoding block mappings in the golden output.
> Please keep it simple and use fixed 64K aligned sizes and offsets.
> It's very unlikely we will support sector sizes larger than 64K, so
> keeping fixed sizes is a lot simpler to understand, maintain and debug
> tests.

Okay, noted.

--NR

>
> Thanks.
>
>> Regards,
>> ojaswin
>>
--
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore