Re: [PATCH] xfs: start inodegc after quota initialization

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

On Wed, Apr 15, 2026 at 12:26:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 13, 2026 at 11:09:40AM -0700, Darrick J. Wong wrote:
> > > index ef1ea8a1238c..d6f75ab41337 100644
> > > --- a/fs/xfs/xfs_mount.c
> > > +++ b/fs/xfs/xfs_mount.c
> > > @@ -1057,7 +1057,6 @@ xfs_mountfs(
> > >  		xfs_clear_using_logged_xattrs(mp);
> > >  
> > >  	/* Enable background inode inactivation workers. */
> > > -	xfs_inodegc_start(mp);
> > >  	xfs_blockgc_start(mp);
> > >  
> > >  	if (xfs_has_metadir(mp)) {
> > > @@ -1143,6 +1142,8 @@ xfs_mountfs(
> > >  		}
> > >  	}
> > >  
> > > +	xfs_inodegc_start(mp);
> > 
> > Why is it correct to defer inodegc until this point?  Can any code
> > between line 1060 and 1145 push an inode to the inodegc mechanism?
> > blockgc can unmap blocks from files, so why is it ok to leave the
> > blockgc_start call where it is?
> 
> Looking at this - I think actually performing inodegc before quotas
> are up sounds dangerous, as we'd miss th quota accounting.  So I
> think we need to defer starting the runners after that.  But we
> should support queuing up inodes before that.  blockgc has
> the same issues.

Hmm.  Very very occasionally I'll see one generic/388 fail in xfs_repair
with slightly wrong quota icount.  /me wonders if this might be it?  In
theory quotacheck could be run to fix the accounting inaccuracies (ugh)
but it's probably better just to defer gc startup.

My original question ("can any code push an inode to gc...?") remains.

--D