From: Christoph Hellwig <hch@lst.de>
To: Yao Sang <sangyao@kylinos.cn>
Cc: fstests@vger.kernel.org, hch@lst.de, zlang@kernel.org
Subject: Re: [RFC] common: skip data write EIO tests on fatal configs
Date: Thu, 18 Jun 2026 11:11:54 +0200 [thread overview]
Message-ID: <20260618091154.GA17530@lst.de> (raw)
In-Reply-To: <20260618034756.615426-1-sangyao@kylinos.cn>
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?
prev parent reply other threads:[~2026-06-18 9:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 3:47 [RFC] common: skip data write EIO tests on fatal configs Yao Sang
2026-06-18 9:11 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260618091154.GA17530@lst.de \
--to=hch@lst.de \
--cc=fstests@vger.kernel.org \
--cc=sangyao@kylinos.cn \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.