On Tue, Aug 27, 2024 at 10:57:34AM +1000, Dave Chinner wrote: > We're discussing how to use the sparse fsbno addressing to allow > resizing of AGs, but we will not be able to do that at all with > rtgroups as they stand. The limitation is a 64 bit global rt extent > address is essential the physical address of the extent in the block > device LBA space. With this series there are not global RT extent addresses, the extents are always relative to the group and an entity only used in the allocator. > /* > * xfs_group - a contiguous 32 bit block address space group > */ > struct xfs_group { > struct xarray xarr; > u32 num_groups; > }; > > struct xfs_group_item { > struct xfs_group *group; /* so put/rele don't need any other context */ > u32 gno; > atomic_t passive_refs; > atomic_t active_refs; What is the point of splitting the group and group_item? This isn't done in the current perag struture either. > Hence I'm wondering if we should actually cap the maximum number of > rtgroups. WE're just about at BS > PS, so with a 64k block size a > single rtgroup can index 2^32 * 2^16 bytes which puts individual > rtgs at 256TB in size. Unless there are use cases for rtgroup sizes > smaller than a few GBs, I just don't see the need for support > theoretical maximum counts on tiny block size filesystems. Thirty > thousand rtgs at 256TB per rtg puts us at 64 bit device size limits, > and we hit those limits on 4kB block sizes at around 500,000 rtgs. > > So do we need to support millions of rtgs? I'd say no.... As said before hardware is having a word with with the 256GB hardware zone size in SMR HDDs. I hope that size will eventually increase, but I would not bet my house on it.