Re: [PATCH 10/36] xfs: export the geometry of realtime groups to userspace

Darrick J. Wong
2024-10-15T19:06:02Z

On Mon, Oct 14, 2024 at 08:30:48PM -0700, hch@infradead.org wrote:
> On Mon, Oct 14, 2024 at 06:14:32PM -0700, Darrick J. Wong wrote:
> > Hmmm so if I'm understanding you correctly: you want to define
> > "capacity" to mean "maximum number of blocks available to userspace"?
>
> Well, what we want is to figure out how much data each rtg (and thus
> hardware zone) can store. This allows databases to align their table
> size to it, and assuming XFS does a good job at data placement get
> optimal performance and write aplification.
>
> > Does that available block count depend on privilege level (ala ext4
> > which always hides 5% of the blocks for root)? I think the answer to
> > that is 'no' because you're really just reporting the number of LBAs in
> > that zone that are available to /any/ application program, and there's a
> > direct mapping from 'available LBAs in a zone' to 'rgblocks available in
> > a rtgroup'.
>
> It's really per-group not total file system global. So the reserves
> and privilege level should not matter.
>
> > But yeah, I agree that it might be nice to know total blocks available
> > in a particular rtgroup. Is it useful to track and report the number of
> > unwritten blocks remaining in that group?
>
> Maybe. Not rally the prime concern. Note that for the zoned code we
> can do that completely trivially, but for the bitmap allocator it would
> be a bit expensive.

Not if we stuffed a field in the summary inode somewhere, but ... I
don't think anyone really cares, and that'd be another piece of metadata
needing cross-checking.

If anyone really wants that kind of info, they can figure it out from
GETFSMAP. If anyone /does/ use GETFSMAP to figure that out and thinks
it's too slow, now would be the time to speak up.

--D