Re: [PATCH 35/43] xfs: enable fsmap reporting for internal RT devices

Darrick J. Wong
2024-12-17T17:06:10Z

On Sun, Dec 15, 2024 at 07:26:13AM +0100, Christoph Hellwig wrote:
> On Fri, Dec 13, 2024 at 03:11:15PM -0800, Darrick J. Wong wrote:
> > > + /* Fabricate an rmap entry for space occupied by the data dev */
> > > + error = xfs_getfsmap_helper(tp, info, &frec);
> > > + if (error)
> > > + return error;
> >
> > Seeing as you report different fmr_device values for the data and rt
> > devices, I'd have though that you'd want the rt fsmappings to start at
> > fmr_physical == 0. But then I guess for the sb_rtstart > 0 case, the
> > rtblock values that get written into the bmbt have that rtstart value
> > added in, don't they?
>
> The bmbt values are all relative to rtstart, the daddr translation is what
> adds the offset. So if we want to take the offset out of the fsmap
> reporting, I'll need new helpers to not add it or manually subtract it
> afterwards. If that's preferred it should be doable, even if the fsmap
> code keeps confusing me more each time I look at it.

I think it's ok if you can leave it as it is. Once you move to
"virtual" fmr_device numbers (aka not a dev_t) then it's up to you to
define how the fmr_physical address space works. It's no longer a
reference to a block device that you can open/pread/etc.

--D