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.
