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

Ojaswin Mujoo
2025-08-05T12:39:51Z

On Tue, Aug 05, 2025 at 07:14:52PM +0930, Qu Wenruo wrote:
>
>
> 在 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

Okay sure, if you feel 64k should be okay for considerable future then
lets hardcode it for simplicity.

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