Re: [PATCH v1] xfs: Fix rgcount/rgsize value reported in XFS_IOC_FSGEOMETRY ioctl

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Dec 09, 2025 at 11:05:21AM +0530, Nirjhar Roy (IBM) wrote:
> 
> On 12/8/25 23:10, Darrick J. Wong wrote:
> > On Mon, Dec 08, 2025 at 08:46:11PM +0530, Nirjhar Roy (IBM) wrote:
> > > With mkfs.xfs -m dir=0 i.e, with XFS_SB_FEAT_INCOMPAT_METADIR
> > > disabled, number of realtime groups should be reported as 1 and
> > > the size of it should be equal to total number of realtime
> > > extents since this the entire realtime filesystem has only 1
> > > realtime group.
> > No.  This (pre-metadir realtime having one group encompassing the entire
> > rt volume) is an implementation detail, not a property of the filesystem
> > geometry.
> > 
> > Or put another way: a metadir rt filesystem with one rtgroup that covers
> > the entire rt device is different from a pre-metadir rt filesystem.
> > xfs_info should present that distinction to userspace, particularly
> > since xfs_scrub cares about that difference.
> 
> Okay, got it. A quick question:
> 
> A metadir rt filesystem will have 1 bitmap/summary file per rt AG, isn't it?

Per rtgroup, but yes.

> If yes, then shouldn't functions like xfs_rtx_to_rbmblock(mp,
> xfs_rtxnum_t        rtx) return offset of the corresponding bitmap file of
> the rt AG where rtx belongs?

xfs_rtx_to_rbmblock is an unfortunate function.  Given an extent number
within an rtgroup, it tells you the corresponding block number within
that rtgroup's bitmap file.  Yes, that's confusing because xfs_rtxnum_t
historically denotes an extent number anywhere on the rt volume.

IOWs, it *should* be an xfs_rgxnum_t (group extent number), which could
be a u32 quantity EXCEPT there's a stupid corner case: pre-metadir rt
volumes being treated as if they have one huge group.

It's theoretically possible for the "single" rtgroup of a pre-metadir rt
volume to have more than 2^32 blocks.  You're unlikely to find one in
practice because (a) old kernels screw up some of the computations and
explode, and (b) lack of sharding means the performance is terrible.

However, we don't want to create copy-pasted twins of the functions so
we took a dumb shortcut and made xfs_rtx_to_rbmblock take xfs_rtxnum_t.
Were someone to make a Rust XFS, they really ought to define separate
types for each distinct geometry usage, and define From traits to go
from one to the other.  Then our typesafety nightmare will be over. ;)

> Right now, looking at the definition of
> xfs_rtx_to_rbmblock() it looks like it calculates the offset as if there is
> only 1 global bitmap file?

Right.

--D

> --NR
> 
> > 
> > --D
> > 
> > > Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
> > > ---
> > >   fs/xfs/libxfs/xfs_sb.c | 8 +++-----
> > >   1 file changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c
> > > index cdd16dd805d7..989553e7ec02 100644
> > > --- a/fs/xfs/libxfs/xfs_sb.c
> > > +++ b/fs/xfs/libxfs/xfs_sb.c
> > > @@ -875,7 +875,7 @@ __xfs_sb_from_disk(
> > >   	} else {
> > >   		to->sb_metadirino = NULLFSINO;
> > >   		to->sb_rgcount = 1;
> > > -		to->sb_rgextents = 0;
> > > +		to->sb_rgextents = to->sb_rextents;
> > >   	}
> > >   	if (to->sb_features_incompat & XFS_SB_FEAT_INCOMPAT_ZONED) {
> > > @@ -1586,10 +1586,8 @@ xfs_fs_geometry(
> > >   	geo->version = XFS_FSOP_GEOM_VERSION_V5;
> > > -	if (xfs_has_rtgroups(mp)) {
> > > -		geo->rgcount = sbp->sb_rgcount;
> > > -		geo->rgextents = sbp->sb_rgextents;
> > > -	}
> > > +	geo->rgcount = sbp->sb_rgcount;
> > > +	geo->rgextents = sbp->sb_rgextents;
> > >   	if (xfs_has_zoned(mp)) {
> > >   		geo->rtstart = sbp->sb_rtstart;
> > >   		geo->rtreserved = sbp->sb_rtreserved;
> > > -- 
> > > 2.43.5
> > > 
> > > 
> -- 
> Nirjhar Roy
> Linux Kernel Developer
> IBM, Bangalore
>