[PATCH] xfs: mark data structures corrupt on EIO and ENODATA

[PATCH] xfs: mark data structures corrupt on EIO and ENODATA

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

I learned a few things this year: first, blk_status_to_errno can return
ENODATA for critical media errors; and second, the scrub code doesn't
mark data structures as corrupt on ENODATA or EIO.

Currently, scrub failing to capture these errors isn't all that
impactful -- the checking code will exit to userspace with EIO/ENODATA,
and xfs_scrub will log a complaint and exit with nonzero status.  Most
people treat fsck tools failing as a sign that the fs is corrupt, but
online fsck should mark the metadata bad and keep moving.

Cc: <stable@vger.kernel.org> # v4.15
Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 fs/xfs/scrub/btree.c   |    2 ++
 fs/xfs/scrub/common.c  |    4 ++++
 fs/xfs/scrub/dabtree.c |    2 ++
 3 files changed, 8 insertions(+)

diff --git a/fs/xfs/scrub/btree.c b/fs/xfs/scrub/btree.c
index cd6f0ff382a7c8..c440f2eb4d1a44 100644
--- a/fs/xfs/scrub/btree.c
+++ b/fs/xfs/scrub/btree.c
@@ -42,6 +42,8 @@ __xchk_btree_process_error(
 		break;
 	case -EFSBADCRC:
 	case -EFSCORRUPTED:
+	case -EIO:
+	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= errflag;
 		*error = 0;
diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c
index 7bfa37c99480f0..5f9be4151d722e 100644
--- a/fs/xfs/scrub/common.c
+++ b/fs/xfs/scrub/common.c
@@ -103,6 +103,8 @@ __xchk_process_error(
 		break;
 	case -EFSBADCRC:
 	case -EFSCORRUPTED:
+	case -EIO:
+	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= errflag;
 		*error = 0;
@@ -177,6 +179,8 @@ __xchk_fblock_process_error(
 		break;
 	case -EFSBADCRC:
 	case -EFSCORRUPTED:
+	case -EIO:
+	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= errflag;
 		*error = 0;
diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c
index 056de4819f866d..a6a5d3a75d994e 100644
--- a/fs/xfs/scrub/dabtree.c
+++ b/fs/xfs/scrub/dabtree.c
@@ -45,6 +45,8 @@ xchk_da_process_error(
 		break;
 	case -EFSBADCRC:
 	case -EFSCORRUPTED:
+	case -EIO:
+	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= XFS_SCRUB_OFLAG_CORRUPT;
 		*error = 0;

Re: [PATCH] xfs: mark data structures corrupt on EIO and ENODATA

[Christoph Hellwig]

On Thu, Dec 18, 2025 at 06:40:50PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> I learned a few things this year: first, blk_status_to_errno can return
> ENODATA for critical media errors; and second, the scrub code doesn't
> mark data structures as corrupt on ENODATA or EIO.
> 
> Currently, scrub failing to capture these errors isn't all that
> impactful -- the checking code will exit to userspace with EIO/ENODATA,
> and xfs_scrub will log a complaint and exit with nonzero status.  Most
> people treat fsck tools failing as a sign that the fs is corrupt, but
> online fsck should mark the metadata bad and keep moving.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

although we really need to stop blindly propagating the block layer
errors.  I'll add that to my ever growing todo list.

Re: [PATCH] xfs: mark data structures corrupt on EIO and ENODATA

[Carlos Maiolino]

On Thu, 18 Dec 2025 18:40:50 -0800, Darrick J. Wong wrote:
> I learned a few things this year: first, blk_status_to_errno can return
> ENODATA for critical media errors; and second, the scrub code doesn't
> mark data structures as corrupt on ENODATA or EIO.
> 
> Currently, scrub failing to capture these errors isn't all that
> impactful -- the checking code will exit to userspace with EIO/ENODATA,
> and xfs_scrub will log a complaint and exit with nonzero status.  Most
> people treat fsck tools failing as a sign that the fs is corrupt, but
> online fsck should mark the metadata bad and keep moving.
> 
> [...]

Applied to for-next, thanks!

[1/1] xfs: mark data structures corrupt on EIO and ENODATA
      commit: f39854a3fb2f06dc69b81ada002b641ba5b4696b

Best regards,
-- 
Carlos Maiolino <cem@kernel.org>