Re: [PATCH 11/24] xfs: create incore realtime group structures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux