Re: [RFC V3 0/3] xfs: Add support to shrink multiple empty AGs

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Oct 22, 2025 at 12:17:27AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 20, 2025 at 09:13:41PM +0530, Nirjhar Roy (IBM) wrote:
> > This work is based on a previous RFC[1] by Gao Xiang and various ideas
> > proposed by Dave Chinner in the RFC[1].
> > 
> > Currently the functionality of shrink is limited to shrinking the last
> > AG partially but not beyond that. This patch extends the functionality
> > to support shrinking beyond 1 AG. However the AGs that we will be remove
> > have to empty in order to prevent any loss of data.
> > 
> > The patch begins with the re-introduction of some of the data
> > structures that were removed, some code refactoring and
> > finally the patch that implements the multi AG shrink design.
> > The final patch has all the details including the definition of the
> > terminologies and the overall design.
> 
> I'm still missing what the overall plan is here.  For "normal" XFS
> setups you'll always have inodes that we can't migrate.  Do you plan
> to use this with inode32 only?

...or resurrect xfs_reno?

Data/attr extent migration might not be too hard if we can repurpose
xfs_zonegc for relocations.  I think moving inodes is going to be very
very difficult because there's no way to atomically update all the
parents.

(Not to mention whatever happens when the inumber abruptly changes)

>                                 Also it would be nice to extent this
> to rtgroups, as we are guaranteed to not have non-migratable metadata
> there and things will actually just work.

Seconded.

--D