Re: [PATCH] xfs: clear zapped attr fork state when bmap repair finds no attr fork

"Darrick J. Wong" <[email protected]>
Newsgroups org.kernel.vger.linux-xfs,org.kernel.vger.linux-kernel
Message-ID <20260715173216.GO7380@frogsfrogsfrogs>
On Wed, Jul 15, 2026 at 06:30:26PM +0800, Qiang Ma wrote:
> xfstests xfs/377 can make xfs_scrub repeatedly check and repair the
> attr block map after inode repair zaps an attr fork.
> 
> When inode repair zaps an attr fork, it records
> XFS_SICK_INO_BMBTA_ZAPPED so that scrub/repair can revisit the attr fork
> block map.  If the fork has been reset to an empty state and removed,
> BMBTA repair has no attr fork mappings to rebuild and can return success.
> 
> The post-repair scrub then runs with XREP_ALREADY_FIXED set, which means
> xchk_file_looks_zapped() deliberately ignores the stale zapped health bit
> and asks xchk_bmap() to check the current attr fork.  For an absent attr
> fork, xchk_bmap() returns -ENOENT.  Returning that error prevents
> xchk_bmap_attr() from marking XFS_SICK_INO_BMBTA_ZAPPED healthy, leaving
> the zapped health state behind even though there are no attr fork mappings
> left to check.
> 
> Treat -ENOENT during post-repair BMBTA revalidation as a clean result for
> the zapped attr fork: clear XFS_SICK_INO_BMBTA_ZAPPED and return success.
> Keep the existing -ENOENT behavior for ordinary scrubs of absent attr
> forks.
> 
> Fixes: d9041681dd2f ("xfs: set inode sick state flags when we zap either ondisk fork")
> Signed-off-by: Qiang Ma <[email protected]>
> ---
>  fs/xfs/scrub/bmap.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/xfs/scrub/bmap.c b/fs/xfs/scrub/bmap.c
> index 70028da1aacc7..0cee51d4338e4 100644
> --- a/fs/xfs/scrub/bmap.c
> +++ b/fs/xfs/scrub/bmap.c
> @@ -1170,6 +1170,11 @@ xchk_bmap_attr(
>  	}
>  
>  	error = xchk_bmap(sc, XFS_ATTR_FORK);
> +	if (error == -ENOENT && (sc->flags & XREP_ALREADY_FIXED)) {
> +		/* A repaired, empty attr fork no longer has mappings to check. */
> +		xchk_mark_healthy_if_clean(sc, XFS_SICK_INO_BMBTA_ZAPPED);
> +		return 0;
> +	}

That makes sense.

Cc: <[email protected]> # v6.8
Reviewed-by: "Darrick J. Wong" <[email protected]>

--D

>  	if (error)
>  		return error;
>  
> -- 
> 2.20.1
> 
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.