FS/XFS testing framework
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: [PATCH RFC] fstests: use MOUNT_OPTIONS to populate TEST_FS_MOUNT_OPTS if possible
Date: Tue,  2 Jun 2026 09:44:22 +0930	[thread overview]
Message-ID: <20260602001422.24364-1-wqu@suse.com> (raw)

If the test config only specifies "MOUNT_OPTIONS", but not
"TEST_FS_MOUNT_OPTS", the mount for TEST_DIR can have inconsistent flag
after _test_cycle_mount().

Here is an very simple test case to show the problem:

 . ./common/preamble
 _begin_fstest auto
 _require_test

 mount | grep "$TEST_DIR"
 _test_cycle_mount
 mount | grep "$TEST_DIR"
 _exit 0

And with "MOUNT_OPTIONS" set to "-o nodatasum" (one of the btrfs mount
option that affects new inodes), but "TEST_FS_MOUNT_OPTS" not set, then
running the test, the output will be:

 QA output created by 348
 /dev/mapper/test-test on /mnt/test type btrfs (rw,relatime,nodatasum,discard=async,space_cache=v2,subvolid=5,subvol=/)
 /dev/mapper/test-test on /mnt/test type btrfs (rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/)

This changed mount option will cause several test cases to fail on btrfs
with MOUNT_OPTIONS="-o nodatasum" set:

- generic/143
- generic/154
- generic/155
- generic/463

All above test case fails because the reflink source is from the initial
test mount, which has "nodatasum" mount option.
But later after _test_cycle_mount(), no more "nodatasum" flags, causing
reflink source and destination have different "nodatasum" flags.
And btrfs will reject such reflink, causing golden output mismatch.

One way to avoid such problem is to set TEST_FS_MOUNT_OPTS to the same
as MOUNT_OPTIONS, but I'm not sure if we really want different options
for test and scratch mounts.

So here as a compromise, set TEST_FS_MOUNT_OPTS to MOUNT_OPTIONS if
the former is not set but the latter is already set by the user.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
Reason for RFC:

- Still didn't get why the initial test mount respects MOUNT_OPTIONS
  If test mount only respects TEST_FS_MOUNT_OPTS, the first mount should
  not get the MOUNT_OPTIONS.

- Not sure if TEST_FS_MOUNT_OPTS is needed
  If not provided, the default config for TEST_FS_MOUNT_OPTS and
  MOUNT_OPTIONS are the same.

  The introduction of TEST_FS_MOUNT_OPTS is from commit 0e9141e49d4a
  ("common: add cifs support"), with extra handling for
  _test_mount_opts().

  But nowadays the special handling is moved to _common_mount_opts(),
  shared by both scratch and test mounts.
  Not sure if there is any fs that requires split options for test and
  scratch.

- Possible reduced coverage
  Ignoring MOUNT_OPTIONS and requiring extra TEST_FS_MOUNT_OPTS can cause
  reduced coverage, as one may expect MOUNT_OPTIONS to affect both test
  and scratch devices.
---
 common/config | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/common/config b/common/config
index d5299d5b..12e94088 100644
--- a/common/config
+++ b/common/config
@@ -419,8 +419,14 @@ _mount_opts()
 	export MOUNT_OPTIONS=$(_common_mount_opts)
 }
 
+# Must be called before _mount_opts().
 _test_mount_opts()
 {
+	# Use $MOUNT_OPTIONS if provided.
+	if [ ! -z "$MOUNT_OPTIONS" ]; then
+		export TEST_FS_MOUNT_OPTS="$MOUNT_OPTIONS"
+		return
+	fi
 	export TEST_FS_MOUNT_OPTS=$(_common_mount_opts)
 }
 
@@ -823,8 +829,8 @@ get_next_config() {
 
 	parse_config_section $1
 	if [ ! -z "$OLD_FSTYP" ] && [ $OLD_FSTYP != $FSTYP ]; then
-		[ -z "$MOUNT_OPTIONS" ] && _mount_opts
 		[ -z "$TEST_FS_MOUNT_OPTS" ] && _test_mount_opts
+		[ -z "$MOUNT_OPTIONS" ] && _mount_opts
 		[ -z "$MKFS_OPTIONS" ] && _mkfs_opts
 		[ -z "$FSCK_OPTIONS" ] && _fsck_opts
 
@@ -915,8 +921,8 @@ if [ -z "$CONFIG_INCLUDED" ]; then
 	fi
 	FSTYP=${FSTYP:=xfs}
 	export FSTYP
-	[ -z "$MOUNT_OPTIONS" ] && _mount_opts
 	[ -z "$TEST_FS_MOUNT_OPTS" ] && _test_mount_opts
+	[ -z "$MOUNT_OPTIONS" ] && _mount_opts
 	[ -z "$MKFS_OPTIONS" ] && _mkfs_opts
 	[ -z "$FSCK_OPTIONS" ] && _fsck_opts
 else
-- 
2.51.2


             reply	other threads:[~2026-06-02  0:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02  0:14 Qu Wenruo [this message]
2026-06-02  6:13 ` [PATCH RFC] fstests: use MOUNT_OPTIONS to populate TEST_FS_MOUNT_OPTS if possible Christoph Hellwig
2026-06-04 16:46   ` Zorro Lang
2026-06-05  4:13     ` Christoph Hellwig
2026-06-06 19:33       ` Zorro Lang
2026-06-04 17:48 ` Zorro Lang
2026-06-06  9:22   ` Qu Wenruo

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=20260602001422.24364-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox