On Wed, Jun 02, 2021 at 11:51:47AM +1000, Dave Chinner wrote:
> On Tue, Jun 01, 2021 at 05:53:00PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@xxxxxxxxxx>
> >
> > Disentangle the dqrele_all inode grab code from the "generic" inode walk
> > grabbing code, and and use the opportunity to document why the dqrele
> > grab function does what it does. Since xfs_inode_walk_ag_grab is now
> > only used for blockgc, rename it to reflect that.
> >
> > Ultimately, there will be four reasons to perform a walk of incore
> > inodes: quotaoff dquote releasing (dqrele), garbage collection of
> > speculative preallocations (blockgc), reclamation of incore inodes
> > (reclaim), and deferred inactivation (inodegc). Each of these four have
> > their own slightly different criteria for deciding if they want to
> > handle an inode, so it makes more sense to have four cohesive igrab
> > functions than one confusing parameteric grab function like we do now.
> >
> > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
> > ---
> > fs/xfs/xfs_icache.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++----
> > 1 file changed, 61 insertions(+), 5 deletions(-)
>
> Looks ok - one minor nit:
>
> > @@ -1642,6 +1682,22 @@ xfs_blockgc_free_quota(
> >
> > /* XFS Incore Inode Walking Code */
> >
> > +static inline bool
> > +xfs_grabbed_for_walk(
> > + enum xfs_icwalk_goal goal,
> > + struct xfs_inode *ip,
> > + int iter_flags)
> > +{
> > + switch (goal) {
> > + case XFS_ICWALK_BLOCKGC:
> > + return xfs_blockgc_igrab(ip, iter_flags);
> > + case XFS_ICWALK_DQRELE:
> > + return xfs_dqrele_igrab(ip);
> > + default:
> > + return false;
> > + }
> > +}
>
> xfs_icwalk_grab() seems to make more sense here.
Ok, changed.
> /me is wondering if all this should eventually end up under a
> xfs_icwalk namespace?
Yeah, I'll throw a renamer patch on the end of this series. Or possibly
just do it after I move the xfs_inode_walk functions to the bottom.
--D
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
