[RFC] common: skip data write EIO tests on fatal configs

[RFC] common: skip data write EIO tests on fatal configs

[Yao Sang]

generic/441 and xfs/656 both inject data write errors after the scratch
filesystem is mounted on dm-error.  They are not testing whether the
filesystem may keep running after the media error; they need the
filesystem to survive long enough to report the error through the path
being tested.  generic/441 checks that writeback errors reach fsync(2),
and xfs/656 checks that healthmon reports the per-I/O error event.

That is the wrong expectation for filesystem configurations where a data
write error is fatal.  Zoned XFS is one such case.  Once a data write
fails, XFS cannot reliably recover its in-core zone allocation state, so
it shuts the mount down.  The shutdown is the correct result, but it makes
these tests fail before they can observe the fsync or healthmon result
they were written to verify.

Add a common helper that describes this precondition and use it in both
tests after mounting the dm-error scratch device.  The helper can be
forced with FS_DATA_WRITE_EIO_SHUTDOWN=yes/no.  In auto mode it currently
detects XFS zoned mounts through the XFS per-mount zoned/max_open_zones
sysfs attribute, so the check follows the filesystem instance rather than
the underlying block queue alone.

Fatal-on-data-write-error configurations are now reported as notrun
instead of as test failures.

Signed-off-by: Yao Sang <sangyao@kylinos.cn>
---
RFC / validation notes:

This patch handles tests that require the filesystem to survive an injected
data write EIO long enough to report the error through the path being tested.
That expectation is not valid for configurations where a data write EIO is
fatal to the filesystem. Zoned XFS is one such configuration because a failed
data writeback can leave the in-core zone allocation state untrustworthy, so
shutting down the mount is expected behavior.

The auto detection is intentionally XFS-specific for now. It checks the XFS
per-mount sysfs attribute zoned/max_open_zones, not the block layer
/sys/block/.../queue/zoned attribute. A zoned block device alone does not
prove that the mounted XFS instance is using zoned filesystem semantics.

One test-number detail is worth calling out. The maintainer report first
mentions generic/441 and xfs/665, but the following fserror/healthmon
description refers to xfs/656. I checked both tests: xfs/656 is the dmerror
plus healthmon data I/O error test and matches the reported failure; xfs/665 is
a systemd xfs_healer / online-repair test and does not exercise dmerror data
write EIO or the healthmon fserror path. Therefore this patch updates xfs/656
and leaves xfs/665 unchanged; the xfs/665 mention looks like a test-number
typo unless there is another affected path.

 common/rc         | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 tests/generic/441 |  1 +
 tests/xfs/656     |  1 +
 3 files changed, 48 insertions(+)

diff --git a/common/rc b/common/rc
index 9632b211..674122ab 100644
--- a/common/rc
+++ b/common/rc
@@ -4162,6 +4162,52 @@ _require_scratch_shutdown_and_syncfs()
 	_require_scratch_shutdown
 }
 
+# Test whether the mounted scratch filesystem treats data write errors as
+# fatal.  Return true if data write errors shut the filesystem down.
+#
+# The filesystem must be mounted before calling this helper because the auto
+# detection path can depend on per-mount sysfs attributes.
+_scratch_data_write_eio_is_fatal()
+{
+	local dev="${1:-$SCRATCH_DEV}"
+
+	case "${FS_DATA_WRITE_EIO_SHUTDOWN:-auto}" in
+	yes|true|1)
+		return 0
+		;;
+	no|false|0)
+		return 1
+		;;
+	auto|"")
+		;;
+	*)
+		_fail "invalid FS_DATA_WRITE_EIO_SHUTDOWN=$FS_DATA_WRITE_EIO_SHUTDOWN"
+		;;
+	esac
+
+	case "$FSTYP" in
+	xfs)
+		# This is an XFS per-mount sysfs attribute, not a block queue
+		# attribute.  Its existence means XFS mounted this instance with
+		# zoned filesystem semantics.
+		_has_fs_sysfs_attr "$dev" "zoned/max_open_zones" && return 0
+		;;
+	esac
+
+	return 1
+}
+
+# Require that data write errors are reported through the regular error
+# reporting path instead of shutting down the filesystem.
+_require_scratch_survives_data_write_errors()
+{
+	local dev="${1:-$SCRATCH_DEV}"
+
+	_scratch_data_write_eio_is_fatal "$dev" || return
+
+	_notrun "$FSTYP treats data write errors as fatal"
+}
+
 _check_s_dax()
 {
 	local target=$1
diff --git a/tests/generic/441 b/tests/generic/441
index 6b48fc9e..b5bab2e0 100755
--- a/tests/generic/441
+++ b/tests/generic/441
@@ -53,6 +53,7 @@ echo "Format and mount"
 _scratch_mkfs > $seqres.full 2>&1
 _dmerror_init no_log
 _dmerror_mount
+_require_scratch_survives_data_write_errors $DMERROR_DEV
 
 _require_fs_space $SCRATCH_MNT 65536
 
diff --git a/tests/xfs/656 b/tests/xfs/656
index 3a867692..d39917f3 100755
--- a/tests/xfs/656
+++ b/tests/xfs/656
@@ -48,6 +48,7 @@ echo "Format and mount"
 _scratch_mkfs > $seqres.full 2>&1
 _dmerror_init no_log
 _dmerror_mount
+_require_scratch_survives_data_write_errors $DMERROR_DEV
 
 _require_fs_space $SCRATCH_MNT 65536
 
-- 
2.25.1

Re: [RFC] common: skip data write EIO tests on fatal configs

[Christoph Hellwig]

On Thu, Jun 18, 2026 at 11:47:56AM +0800, Yao Sang wrote:
> The auto detection is intentionally XFS-specific for now. It checks the XFS
> per-mount sysfs attribute zoned/max_open_zones, not the block layer
> /sys/block/.../queue/zoned attribute. A zoned block device alone does not
> prove that the mounted XFS instance is using zoned filesystem semantics.

Yeah, make sense.

> One test-number detail is worth calling out. The maintainer report first
> mentions generic/441 and xfs/665, but the following fserror/healthmon
> description refers to xfs/656. I checked both tests: xfs/656 is the dmerror
> plus healthmon data I/O error test and matches the reported failure; xfs/665 is

Sorry, I fat-fingered the number.

> +_scratch_data_write_eio_is_fatal()
> +{
> +	local dev="${1:-$SCRATCH_DEV}"

I'll defer to Zorro, but normally either requiring an argument
always or neve seems nice.  And my preference here would be to
always pass the device, and not have _scratch in the name.

> +
> +	case "${FS_DATA_WRITE_EIO_SHUTDOWN:-auto}" in
> +	yes|true|1)
> +		return 0
> +		;;
> +	no|false|0)
> +		return 1
> +		;;
> +	auto|"")
> +		;;
> +	*)
> +		_fail "invalid FS_DATA_WRITE_EIO_SHUTDOWN=$FS_DATA_WRITE_EIO_SHUTDOWN"
> +		;;
> +	esac

I don't understand what this part is about at all.

> +
> +	case "$FSTYP" in
> +	xfs)
> +		# This is an XFS per-mount sysfs attribute, not a block queue
> +		# attribute.  Its existence means XFS mounted this instance with
> +		# zoned filesystem semantics.
> +		_has_fs_sysfs_attr "$dev" "zoned/max_open_zones" && return 0
> +		;;
> +	esac
> +
> +	return 1

This part looks fine.

> +}
> +
> +# Require that data write errors are reported through the regular error
> +# reporting path instead of shutting down the filesystem.
> +_require_scratch_survives_data_write_errors()
> +{
> +	local dev="${1:-$SCRATCH_DEV}"
> +
> +	_scratch_data_write_eio_is_fatal "$dev" || return
> +
> +	_notrun "$FSTYP treats data write errors as fatal"
> +}

Do we need both survives and fatal versions of this?  Or decide
on one polarity and be done with it?