On Mon, Oct 14, 2024 at 08:30:48PM -0700, hch@xxxxxxxxxxxxx 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
