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.
/me is wondering if all this should eventually end up under a
xfs_icwalk namespace?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
