On Mon, Aug 26, 2024 at 09:38:16PM -0700, Christoph Hellwig wrote: > 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. I think xfs_group encapsulates/replaces the radix tree root in struct xfs_mount, and the xarray inside it points to xfs_group_item objects. > > 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. Wait, 256 *gigabytes*? That wouldn't be such a bad minimum. --D