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

Filipe Manana
2025-08-05T10:48:03Z

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.

Thanks.

>
> Regards,
> ojaswin
>