[PATCHSET] fstests: more random fixes for v2025.12.09

[PATCHSET] fstests: more random fixes for v2025.12.09

[Darrick J. Wong]

Hi all,

Here's the usual odd fixes for fstests.

If you're going to start using this code, I strongly recommend pulling
from my git trees, which are linked below.

With a bit of luck, this should all go splendidly.
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
Commits in this patchset:
 * check: put temporary files in TMPDIR, not /tmp
 * common/rc: fix _xfs_is_realtime_file for internal rt devices
 * xfs/649: fix various problems
---
 check             |    2 +-
 common/preamble   |    2 +-
 common/xfs        |    6 +++---
 tests/generic/002 |   16 ++++++++--------
 tests/xfs/649     |    7 ++++---
 5 files changed, 17 insertions(+), 16 deletions(-)

[PATCH 1/3] check: put temporary files in TMPDIR, not /tmp

[Darrick J. Wong]

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

Nowadays, systemd will auto-remove files from /tmp after 10 days.  If
you want to run a testcase for more than that duration (e.g.
SOAK_DURATION=14d) then the test will fail after the .out file is
deleted:

 xfs/286            _check_xfs_filesystem: filesystem on /dev/sda4 is inconsistent (r)
 (see /var/tmp/fstests/xfs/286.full for details)
 sed: can't read /tmp/2098.out: No such file or directory
 - output mismatch (see /var/tmp/fstests/xfs/286.out.bad)
 mv: cannot stat '/tmp/2098.out': No such file or directory
 diff: /var/tmp/fstests/xfs/286.out.bad: No such file or directory

This happens because systemd-tmpfiles garbage collects any file in /tmp
that becomes older than 10 days:

 $ cat /usr/lib/tmpfiles.d/tmp.conf
 #  This file is part of systemd.
 #
 #  systemd is free software; you can redistribute it and/or modify it
 #  under the terms of the GNU Lesser General Public License as published by
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.

 # See tmpfiles.d(5) for details.

 # Clear tmp directories separately, to make them easier to override
 q /tmp 1777 root root 10d
 q /var/tmp 1777 root root 30d

This is now the default in Debian 13 (D12 never deleted anything) which
is why I didn't notice this until I upgraded a couple of weeks ago.
Most people aren't going to be running a single testcase for more than
10 days so I'll go with the least invasive solution that I can think of.

Allow system administrators or fstests runners to set TMPDIR to a
directory that won't get purged, and make fstests follow that.  Fix up
generic/002 so that it doesn't use $tmp for paths on the test
filesystem.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 check             |    2 +-
 common/preamble   |    2 +-
 tests/generic/002 |   16 ++++++++--------
 3 files changed, 10 insertions(+), 10 deletions(-)


diff --git a/check b/check
index c897afbb419612..cd7a79347eac28 100755
--- a/check
+++ b/check
@@ -4,7 +4,7 @@
 #
 # Control script for QA
 #
-tmp=/tmp/$$
+tmp="${TMPDIR:-/tmp}/$$"
 status=0
 needwrap=true
 needsum=true
diff --git a/common/preamble b/common/preamble
index 51d03396c96864..1c1eb348a88114 100644
--- a/common/preamble
+++ b/common/preamble
@@ -47,7 +47,7 @@ _begin_fstest()
 	echo "QA output created by $seq"
 
 	here=`pwd`
-	tmp=/tmp/$$
+	tmp="${TMPDIR:-/tmp}/$$"
 	status=1	# failure is the default!
 
 	_register_cleanup _cleanup
diff --git a/tests/generic/002 b/tests/generic/002
index b202492b49a73c..6df57a7a1353c7 100755
--- a/tests/generic/002
+++ b/tests/generic/002
@@ -20,31 +20,31 @@ _require_hardlinks
 echo "Silence is goodness ..."
 
 # ensure target directory exists
-mkdir `dirname $TEST_DIR/$tmp` 2>/dev/null
+mkdir `dirname $TEST_DIR/tmp` 2>/dev/null
 
-touch $TEST_DIR/$tmp.1
+touch $TEST_DIR/tmp.1
 for l in 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
 do
-    ln $TEST_DIR/$tmp.1 $TEST_DIR/$tmp.$l
-    x=`$here/src/lstat64 $TEST_DIR/$tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
+    ln $TEST_DIR/tmp.1 $TEST_DIR/tmp.$l
+    x=`$here/src/lstat64 $TEST_DIR/tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
     if [ "$l" -ne $x ]
     then
 	echo "Arrgh, created link #$l and lstat64 looks like ..."
-	$here/src/lstat64 $TEST_DIR/$tmp.1
+	$here/src/lstat64 $TEST_DIR/tmp.1
 	status=1
     fi
 done
 
 for l in 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
 do
-    x=`$here/src/lstat64 $TEST_DIR/$tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
+    x=`$here/src/lstat64 $TEST_DIR/tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
     if [ "$l" -ne $x ]
     then
 	echo "Arrgh, about to remove link #$l and lstat64 looks like ..."
-	$here/src/lstat64 $TEST_DIR/$tmp.1
+	$here/src/lstat64 $TEST_DIR/tmp.1
 	status=1
     fi
-    rm -f $TEST_DIR/$tmp.$l
+    rm -f $TEST_DIR/tmp.$l
 done
 
 # success, all done

[PATCH 2/3] common/rc: fix _xfs_is_realtime_file for internal rt devices

[Darrick J. Wong]

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

Now that we can have internal realtime devices, it's possible to have a
realtime filesystem without setting USE_EXTERNAL=yes or SCRATCH_RTDEV.
Use the existing _xfs_has_feature helper to figure out if the given path
points to a filesystem with an online realtime volume.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 common/xfs |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


diff --git a/common/xfs b/common/xfs
index ffdb82e6c970ba..8b1b87413659ad 100644
--- a/common/xfs
+++ b/common/xfs
@@ -253,9 +253,9 @@ _xfs_get_dir_blocksize()
 # Decide if this path is a file on the realtime device
 _xfs_is_realtime_file()
 {
-	if [ "$USE_EXTERNAL" != "yes" ] || [ -z "$SCRATCH_RTDEV" ]; then
-		return 1
-	fi
+	local mntpt="$(findmnt --target "$1" --noheadings --output TARGET)"
+
+	_xfs_has_feature $mntpt realtime || return 1
 	$XFS_IO_PROG -c 'stat -v' "$1" | grep -q -w realtime
 }
 

[PATCH 3/3] xfs/649: fix various problems

[Darrick J. Wong]

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

Fix a couple of problems with this new test:

First, the comment for the $attr_size_bytes check says that the maximum
size of a single xattr value is 64k.  This is true, but the check
triggers the warning even when the size is exactly 64k.

Second, the test fails to format with 32k and 64k fsblock size
filesystems because the scsi_debug device size is 128M, and that's not
large enough for the minimum log size.  Raise that to 320M.

Cc: <fstests@vger.kernel.org> # v2025.12.09
Fixes: 5760b2105985bf ("xfs: test case for handling io errors when reading extended attributes")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 tests/xfs/649 |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)


diff --git a/tests/xfs/649 b/tests/xfs/649
index f7b559f72fe913..56277c62932e16 100755
--- a/tests/xfs/649
+++ b/tests/xfs/649
@@ -48,14 +48,15 @@ _require_attrs user
 # If SELinux is enabled common/config sets a default context, which breaks this test.
 export SELINUX_MOUNT_OPTIONS=""
 
-scsi_debug_dev=$(_get_scsi_debug_dev)
+# need at least 320m to format with 32/64k fsblock size
+scsi_debug_dev=$(_get_scsi_debug_dev 512 512 0 321)
 scsi_debug_opt_noerror=0
 scsi_debug_opt_error=${scsi_debug_opt_error:=2}
 test -b $scsi_debug_dev || _notrun "Failed to initialize scsi debug device"
 echo "SCSI debug device $scsi_debug_dev" >>$seqres.full
 
 SCRATCH_DEV=$scsi_debug_dev
-_scratch_mkfs >> $seqres.full
+_scratch_mkfs >> $seqres.full || _notrun "could not format filesystem"
 _scratch_mount
 
 block_size=$(_get_file_block_size $SCRATCH_MNT)
@@ -77,7 +78,7 @@ test_attr()
 	# The maximum size for a single value is ATTR_MAX_VALUELEN (64*1024)
 	# If we wanted to test a larger range of extent combinations the test
 	# would need to use multiple values.
-	[[ $attr_size_bytes -ge 65536 ]] && echo "Test would need to be modified to support > 64k values for $attr_blocks blocks".
+	[[ $attr_size_bytes -gt 65536 ]] && echo "Test would need to be modified to support > 64k values for $attr_blocks blocks".
 
 	echo $scsi_debug_opt_noerror > /sys/module/scsi_debug/parameters/opts
 

Re: [PATCH 1/3] check: put temporary files in TMPDIR, not /tmp

[Christoph Hellwig]

On Tue, Dec 16, 2025 at 10:29:25AM -0800, Darrick J. Wong wrote:
> Allow system administrators or fstests runners to set TMPDIR to a
> directory that won't get purged, and make fstests follow that.  Fix up
> generic/002 so that it doesn't use $tmp for paths on the test
> filesystem.

The second part feels like it's worth a separate patch to make it more
clearly stand out.  Either way all the changes looks good:

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

Re: [PATCH 2/3] common/rc: fix _xfs_is_realtime_file for internal rt devices

[Christoph Hellwig]

On Tue, Dec 16, 2025 at 10:29:41AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Now that we can have internal realtime devices, it's possible to have a
> realtime filesystem without setting USE_EXTERNAL=yes or SCRATCH_RTDEV.
> Use the existing _xfs_has_feature helper to figure out if the given path
> points to a filesystem with an online realtime volume.

Looks good:

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

Re: [PATCH 3/3] xfs/649: fix various problems

[Christoph Hellwig]

On Tue, Dec 16, 2025 at 10:29:56AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Fix a couple of problems with this new test:

It looks like this patch got dropped again?  While my git repository
has the commit ID, I can't find the test in the patches-in-queue or
for-next branches.

The changes themselves look sane to me.

Re: [PATCH 3/3] xfs/649: fix various problems

[Darrick J. Wong]

On Wed, Dec 17, 2025 at 02:25:11AM -0800, Christoph Hellwig wrote:
> On Tue, Dec 16, 2025 at 10:29:56AM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Fix a couple of problems with this new test:
> 
> It looks like this patch got dropped again?  While my git repository
> has the commit ID, I can't find the test in the patches-in-queue or
> for-next branches.
> 
> The changes themselves look sane to me.

You might've pulled my for-next branch.  IIRC I've never sent this one
to the list, so Zorro has never seen it.

--D

Re: [PATCH 3/3] xfs/649: fix various problems

[Zorro Lang]

On Wed, Dec 17, 2025 at 08:12:32PM -0800, Darrick J. Wong wrote:
> On Wed, Dec 17, 2025 at 02:25:11AM -0800, Christoph Hellwig wrote:
> > On Tue, Dec 16, 2025 at 10:29:56AM -0800, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > Fix a couple of problems with this new test:
> > 
> > It looks like this patch got dropped again?  While my git repository
> > has the commit ID, I can't find the test in the patches-in-queue or
> > for-next branches.
> > 
> > The changes themselves look sane to me.
> 
> You might've pulled my for-next branch.  IIRC I've never sent this one
> to the list, so Zorro has never seen it.

I just checked my mailbox, I didn't find an email with this subject or even
with xfs/649. But our mail server filter out some patch emails sometimes,
so if I missed your patches, please feel free to ping me :)

Thanks,
Zorro

> 
> --D
>