On Mon, Aug 26, 2024 at 10:17:19PM -0700, Darrick J. Wong wrote:
> > 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.
Ahh. So it's now a xfs_group structure, but a xfs_groups one,
with the group item really being xfs_group.
>
> > > 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.
Sorry, MB. My units really suck this morning :)
