This testcase tries to check whether f2fs can handle "usrjquota="
during remount correctly, it expects kernel will encounter NULL
pointer dereference bug w/o the fix ("f2fs: fix to avoid NULL pointer
dereference in f2fs_check_quota_consistency()").
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Brian Foster [Fri, 26 Sep 2025 12:12:49 +0000 (08:12 -0400)]
common/rc: destroy loop dev before fallback recreation
When running fstests on an s390x box I observed failure to unmount
filesystem errors due to stale loop devices being left around. This
root caused down to generic/361 leaving around an attached loop0
device. On further inspection, the test actually created two loop
devices (loop0 and loop1), and executed on and cleaned up the
latter.
The origin of the former appears to be that the initial losetup
command in _create_loop_device() fails due to $dio_args in this
environment, but still creates the loop device. For example:
# losetup --direct-io=on -f --show /mnt/scratch/fs.img
/dev/loop0
losetup: /dev/loop0: set direct io failed: Invalid argument
# losetup -a
/dev/loop0: [64771]:131 (/mnt/scratch/fs.img)
The helper then goes on to create loop1, but it or the test never
deals with loop0. To avoid this problem, detach any old loop device
if one was set up before the fallback losetup command.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
fstests: generic/733: avoid output difference due to bash's version
[FALSE ALERT]
When running generic/733 with bash 5.3.3 (any thing newer than 5.3.0
will reproduce the bug), the test case will fail like the following:
generic/733 19s ... - output mismatch (see /home/adam/xfstests/results//generic/733.out.bad)
--- tests/generic/733.out 2025-09-04 17:30:08.568000000 +0930
+++ /home/adam/xfstests/results//generic/733.out.bad 2025-09-04 17:30:32.898475103 +0930
@@ -2,5 +2,5 @@
Format and mount
Create a many-block file
Reflink the big file
-Terminated
+Terminated $here/src/t_reflink_read_race "$testdir/file1" "$testdir/file2" "$testdir/outcome" &>> $seqres.full
test completed successfully
...
(Run 'diff -u /home/adam/xfstests/tests/generic/733.out /home/adam/xfstests/results//generic/733.out.bad' to see the entire diff)
[CAUSE]
The failure is fs independent, but bash version dependent.
In bash v5.3.x, the job control will output the command which triggered
the job control (from termination to core dump etc).
The "Terminated" message is not from the program, but from bash's job
control, thus redirection won't hide that message.
[FIX]
Run the command in a command group, which will be executed in a
subshell.
By this we can redirect the output of the subshell, including the job
control message, thus hide the different output pattern caused by
different bash versions.
Thankfully this particular test case does extra checks on the outcome
file to determine if the program is properly terminated, thus we are
safe to move the "Terminated" line from the golden output to
seqres.full.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/228 1s ... - output mismatch (see /home/adam/xfstests/results//generic/228.out.bad)
--- tests/generic/228.out 2025-09-04 15:15:08.965000000 +0930
+++ /home/adam/xfstests/results//generic/228.out.bad 2025-09-04 15:16:05.627457599 +0930
@@ -1,6 +1,6 @@
QA output created by 228
File size limit is now set to 100 MB.
Let us try to preallocate 101 MB. This should fail.
-File size limit exceeded
+File size limit exceeded $XFS_IO_PROG -f -c 'falloc 0 101m' $TEST_DIR/ouch
Let us now try to preallocate 50 MB. This should succeed.
Test over.
...
(Run 'diff -u /home/adam/xfstests/tests/generic/228.out /home/adam/xfstests/results//generic/228.out.bad' to see the entire diff)
Ran: generic/228
Failures: generic/228
Failed 1 of 1 tests
[CAUSE]
The "File size limit exceeded" line is never from xfs_io, but the
coredump from bash itself.
And with latest 5.3.x bash, it added extra dump during such core dump
handling (even if we have explicitly skipped the coredump).
[FIX]
Instead of relying on bash to do the coredump, which is unreliable
between different bash versions as I have shown above, ignore the
SIGXFSZ signal so that xfs_io will do the error output, which is more
reliable than bash.
And since we do not need to bother the coredump behavior, remove all the
cleanup and preparation for coredump.
There's another btrfs kernel commit that landed in v6.16-rc1 and fixes
another EOF truncation bug exposed by this test case, so add the commit
in a _fixed_by_kernel_commit call.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Ojaswin Mujoo [Tue, 5 Aug 2025 09:25:56 +0000 (14:55 +0530)]
generic/365: Fix false failure when mapping ends with free space
If we have a small FS where the first free space mapping is also the
last mapping of the FS, then the following sub-test fails:
echo "test whatever came after freesp"
$XFS_IO_PROG -c "fsmap -d $((freesp_end + 2)) $((freesp_end + 3))" $SCRATCH_MNT
since there is nothing after the freespace. Fix this by punching a 1M
hole in a 3M file to ensure that the first free space is always
surrounded by allocated blocks.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Tested-by: Disha Goel <disgoel@linux.ibm.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Wed, 27 Aug 2025 01:42:50 +0000 (11:12 +0930)]
fstests: btrfs: add a new test case to verify compressed read
The new test case is a regression test related to the block size < page
size handling of compressed read.
The test case will only be triggered with 64K page size and 4K btrfs
block size.
I'm using aarch64 with 64K page size to trigger the regression.
The test case will create the following file layout:
base:
[0, 64K): Single compressed data extent at bytenr X.
new:
[0, 32K): Reflinked from base [32K, 64K)
[32K, 60K): Reflinked from base [0, 28K)
[60K, 64K): New 4K write
The range [0, 32K) and [32K, 64K) are pointing to the same compressed
data.
The last 4K write is a special workaround. It is a block aligned
write, thus it will create the folio but without reading out the
remaing part.
This is to avoid readahead path, which has the proper fix.
We want single folio read without readahead.
Then output the file "new" just after the last 4K write, then cycle
mount and output the content again.
For patched kernel, or with 4K page sized system, the test will pass,
the resulted content will not change during mount cycles.
For unpatched kernel and with 64K page size, the test will fail, the
content after the write will be incorrect (the range [32K, 60K) will be
zero), but after a mount cycle the content is correct again.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/450: don't hang when running on devices with protection information
The dm thinp target does not work on devices with protection information,
and the udevadm settle command simply hangs when lvcreate failed because
of that. Avoid that by doing a strategic _notrun when lvcreate fails.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/081: don't hang when running on devices with protection information
The dm snapshot target does not work on devices with protection
information, and the udevadm settle command simply hangs when lvcreate
failed because of that. Avoid that by doing a strategic _notrun when
lvcreate fails.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/563: Increase the iosize to cover for btrfs higher node sizes
When tested with block size/node size 64K on btrfs, then the test fails
with the folllowing error:
QA output created by 563
read/write
read is in range
-write is in range
+write has value of 8855552
+write is NOT in range 7969177.6 .. 8808038.4
write -> read/write
...
The slight increase in the amount of bytes that are written is because
of the increase in the the nodesize(metadata) and hence it exceeds
the tolerance limit slightly. Fix this by increasing the iosize.
Increasing the iosize increases the tolerance range and covers the
tolerance for btrfs higher node sizes.
A very detailed explanation is given by Qu Wenruo in [1]
btrfs/137: Make this test compatible with all supported block sizes
For large block sizes like 64k it failed simply because this
test was written with 4k block size in mind.
The first few lines of the error logs are as follows:
generic/274: Make the pwrite block sizes and offsets to 64k
This test was written with 4k block size in mind and it fails with
64k block size when tested with btrfs.
The test first does pre-allocation, then fills up the
filesystem. After that it tries to fragment and fill holes at offsets
of 4k(i.e, 1 fsblock) - which works fine with 4k block size, but with
64k block size, the test tries to fragment and fill holes within
1 fsblock(of size 64k). This results in overwrite of 64k fsblocks
and the write fails. The reason for this failure is that during
overwrite, there is no more space available for COW.
Fix this by changing the pwrite block size and offsets to 64k
so that the test never tries to punch holes or overwrite within 1 fsblock
and the test becomes compatible with all block sizes.
For non-COW filesystems/files, this test should work even if the
underlying filesytem block size > 64k.
btrfs/301: Make the test compatible with all the supported block sizes
With large block sizes like 64k the test failed with the
following logs:
QA output created by 301
basic accounting
+subvol 256 mismatched usage 33947648 vs 4587520 (expected data 4194304 expected meta 393216 diff 29360128)
+subvol 256 mismatched usage 168165376 vs 138805248 (expected data 138412032 expected meta 393216 diff 29360128)
+subvol 256 mismatched usage 33947648 vs 4587520 (expected data 4194304 expected meta 393216 diff 29360128)
+subvol 256 mismatched usage 33947648 vs 4587520 (expected data 4194304 expected meta 393216 diff 29360128)
fallocate: Disk quota exceeded
The test creates nr_fill files each of size 8k. Now with 64k
block size, 8k sized files occupy more than the expected sizes (i.e, 8k)
due to internal fragmentation, since 1 file will occupy at least 1
fsblock. Fix this by making the file size 64k, which is aligned
with all the supported block sizes.
btrfs/237: skip test on devices with conventional zones
Skip btrfs/237 on devices with conventional zones, as we cannot force data
allocation on a sequential zone at the moment and conventional zones
cannot be reset, making the test invalid.
Furthermore limit the output of get_data_bg() and get_data_bg_physical()
to the first address.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Thu, 21 Aug 2025 23:35:41 +0000 (16:35 -0700)]
btrfs/301: test nested squota teardown
Nested squotas with snapshots is the most complicated case, so add some
extra checks to it. Specifically, ensure that full tear down of the
subvols and parent qgroups works properly.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Sat, 16 Aug 2025 07:29:09 +0000 (15:29 +0800)]
f2fs/012: adapt lookup_mode=x mount option
w/ below change [1], f2fs will enable lookup_mode=perf by default, it
will change f2fs dirent lookup method from linear based lookup to hash
based lookup.
So that, f2fs will ignore sb.s_encoding_flags by default, which is not
compatible w/ f2fs/012 testcase, in where it will control lookup method
by configuring this flag w/ fsck.f2fs.
To avoid failure of f2fs/012, let's check whether f2fs has supported
"lookup_mode=auto" mount option, mount w/ the option if it can,
otherwise, don't.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Daniel Lee <chullee@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Fri, 15 Aug 2025 08:14:05 +0000 (16:14 +0800)]
f2fs: do sanity check on i_xattr_nid
This is a regression test:
1. create directory
2. add a new xattr entry to create xattr node
3. use inject.f2fs to inject nid of xattr node w/ ino in a file
4. check whether f2fs kernel module will detect and report such
corruption in the file
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Fri, 15 Aug 2025 08:14:04 +0000 (16:14 +0800)]
f2fs: do sanity check on mapping table
This is a regression test:
1. create a file
2. write file to create a direct node at special offset
3. use inject.f2fs to inject nid of direct node w/ ino of the inode
4. check whether f2fs kernel module will detect and report such
corruption in the fil
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Fri, 15 Aug 2025 08:14:03 +0000 (16:14 +0800)]
f2fs: check data eof after partial truncation on compressed cluster
This is a regression testcase, it is added to check below case
and its variants:
- write 16k data into compressed file (data will be compressed)
- truncate file to 12k (truncate partial data in compressed cluster)
- truncate file to 20k
- verify data in range of [12k, 16k] to see whether data is all zero
or not
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Mon, 4 Aug 2025 11:40:16 +0000 (19:40 +0800)]
f2fs: test mount options for zoned device
As f2fs changes to use new mount APIs, let's add a new testcase
to check mount result for special mount options for zoned device
and their combinations, in order to detect any inconsistency during
mount.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Mon, 4 Aug 2025 11:40:15 +0000 (19:40 +0800)]
f2fs: test special mount options
As f2fs changes to use new mount APIs, let's add a new testcase
to check mount result for all f2fs supported special mount options
and their combinations, in order to detect any inconsistency during
mount.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Mon, 4 Aug 2025 11:40:14 +0000 (19:40 +0800)]
f2fs: test common mount options
As f2fs changes to use new mount APIs, let's add a new testcase
to check mount result for all f2fs supported common mount options
and their combinations, in order to detect any inconsistency during
mount.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Fri, 15 Aug 2025 14:45:55 +0000 (22:45 +0800)]
overlay/005: only run for xfs underlying fs
When we runs overlay/005 on a system without xfs module, it always
fails as "unknown filesystem type xfs", due to this case require xfs
to be the underlying fs explicitly:
Brian Foster [Thu, 7 Aug 2025 14:56:26 +0000 (10:56 -0400)]
xfs: test iomap zero range via fsx and error tag
iomap supports a zero range operation based on buffered writes. This
mechanism is used in limited spots, such as partial block zeroing,
etc., because usually for larger zeroing ops it is more efficient to
punch a hole and allocate unwritten extents.
This means iomap zero range has limited production test coverage
even though it has some particular corner cases that warrant test
coverage. XFS supports an error injection knob to force use of iomap
zero range on fallocate zero range operations. Add a test to run fsx
with this knob enabled to provide more zeroing test coverage.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
John Garry [Thu, 31 Jul 2025 09:18:13 +0000 (09:18 +0000)]
generic/765: modify some steps to fix test
Now that multi-block atomics writes are supported, some of the test steps
are failing. Those steps relied on supporting single-block atomic writes
only.
The current test steps are as follows:
a. Ensure statx for bdev returns same awu_min/max as from sysfs
b. test mkfs for each size of bdev atomic writes capabilities and supported
FS block size
c. Ensure atomic limits for file match block size for each in b.
d. Ensure that we can atomic write block size for each in b.
e. Ensure that we cannot write file for 2* bdev awu_max or bdev awu_max /2
Make test pass again by:
1. Modify c. to ensure file awu_max >= block size
2. dropping e. We already have tests to ensure that we can only write a
size >= awu_min and <= awu_max in generic/767
Signed-off-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Jul 2025 20:09:48 +0000 (13:09 -0700)]
xfs/838: actually force usage of the realtime device
Actually force the filesystem to create testfile as a realtime file so
that the test does anything useful.
Cc: fstests@vger.kernel.org # v2025.07.13 Fixes: 7ca990e22e0d61 ("xfs: more multi-block atomic writes tests") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Jul 2025 20:09:32 +0000 (13:09 -0700)]
generic/767: allow on any atomic writes filesystem
This test now works correctly for any atomic writes geometry since we
control all the parameters. Remove this restriction so that we can get
minimal testing on ext4 and fuse2fs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Jul 2025 20:09:17 +0000 (13:09 -0700)]
generic/767: only test the hardware atomic write unit
This test sets up scsi_debug so that we can test the fs and block layer
code for hardware-accelerated atomic writes (and not just a software
fallback). However, the userspace ABI for detecting atomic write
geometry has changed since the start of development (to include said
software fallback) so we must add some extra code to find the real
hardware capabilities, and base the write sizes based on that.
This fixes a test failure with 32k blocksizes because the advertised
atomic_write_unit_max is 128M and fallocate quickly runs out of space.
While we're at it fix a stupid variable usage bug in the loop.
Cc: fstests@vger.kernel.org # v2025.07.13 Fixes: fa8694c823d853 ("generic: various atomic write tests with hardware and scsi_debug") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Jul 2025 20:09:01 +0000 (13:09 -0700)]
generic/767: require fallocate support
This test fails on filesystems that don't support fallocate, so screen
them out.
Cc: fstests@vger.kernel.org # v2025.07.13 Fixes: fa8694c823d853 ("generic: various atomic write tests with hardware and scsi_debug") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Make sure the lba size of the loop devices created for the metadump
tests actually match that of the real SCRATCH_ devices or else the tests
will fail.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Jul 2025 20:10:19 +0000 (13:10 -0700)]
xfs/259: try to force loop device block size
Starting with 6.15-rc1, loop devices created with directio mode enabled
will set their logical block size to whatever STATX_DIO_ALIGN on the
host filesystem reports. If you want fstests to set up loop devices in
directio mode and TEST_DEV is a block device with 4k sectors, this will
cause conflicts with this test's usage of mkfs with different block
sizes. Enhance the existing _create_loop_device so that tests can force
the loop device block size to 512 bytes, which is implied by scenarios
such as "device size is 4T - 2048 bytes".
Also fix xfs/078 which simply needs the blocksize to be set.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Wed, 30 Jul 2025 19:21:41 +0000 (20:21 +0100)]
generic: test fsync of file with 0 links and extents
Create two files, the first one with some data, and then fsync both
files. The first file is fsynced after removing its hardlink. After a
power failure we expect the fs to be mountable and for only the second
file to be present.
This exercises an issue found in btrfs and fixed by the following patch:
btrfs: fix log tree replay failure due to file with 0 links and extents
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
_test_remount_barrier() is skipped on kernels newer than v4.19 where the
barrier options have been removed, and this is detected by matching the
mount command output for a "bad option" error.
Recent util-linux commit 9da5644e414c ("libmount: report kernel message
from new API"), which was introduced in v2.41 release changed that error
message from the old hardcoded one:
mount: /mnt/scratch: mount point not mounted or bad option.
to the newer, and more specific coming from the kernel:
Update the test to account for that change so that the unsupported
options can be properly detected again and for this part of the test to
be skipped successfully.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Wed, 30 Jul 2025 23:03:07 +0000 (16:03 -0700)]
btrfs/301: enhance nested simple quotas test
We had a bug with qgroup accounting with 2+ layers, which was most
easily detected with a slightly more complex nested squota hierarchy.
Make the nested squota test case a tiny bit more complex to capture this
test as well.
The kernel patch that this change exercises is:
btrfs: fix iteration bug in __qgroup_excl_accounting()
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 24 Jul 2025 12:05:59 +0000 (13:05 +0100)]
generic/211: verify if the filesystem being tested supports in place writes
The test currently assumes the filesystem can do in place writes (no
Copy-On-Write, no allocation of new extents) when overwriting a file.
While that is the case for most filesystems in most configurations, there
are exceptions such as zoned xfs where overwriting results in allocating
new extents for the new data.
So make the test check that in place writes are supported and skip the
test if they are not supported.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
ext4/028: require that the scratch file system has the extent feature enabled
If the file system configuration has journalling enabled, but doesn't
have the extent feature enabled (e.g., when testing the ext3
configuration) the test will fail since _scratch_populate_cached
creates files with extents enabled. So add a check to skip the test
in that case.
Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
This test fails on ext4 if the commit 4a622e4d477b
is missing in the kernel. Add this hint.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/282: use timed writes to make sure scrub has enough run time
[FAILURE]
Test case btrfs/282 still fails on some setup:
output mismatch (see /opt/xfstests/results//btrfs/282.out.bad)
--- tests/btrfs/282.out 2025-06-27 22:00:35.000000000 +0200
+++ /opt/xfstests/results//btrfs/282.out.bad 2025-07-08 20:40:50.042410321 +0200
@@ -1,3 +1,4 @@
QA output created by 282
wrote 2147483648/2147483648 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+scrub speed 2152038400 Bytes/s is not properly throttled, target is 1076019200 Bytes/s
...
(Run diff -u /opt/xfstests/tests/btrfs/282.out /opt/xfstests/results//btrfs/282.out.bad to see the entire diff)
[CAUSE]
Checking the full output, it shows the scrub is running too fast:
Starting scrub on devid 1
scrub done for c45c8821-4e55-4d29-8172-f1bf30b7182c
Scrub started: Tue Jul 8 20:40:47 2025
Status: finished
Duration: 0:00:00 <<<
Total to scrub: 2.00GiB
Rate: 2.00GiB/s
Error summary: no errors found
Starting scrub on devid 1
scrub done for c45c8821-4e55-4d29-8172-f1bf30b7182c
Scrub started: Tue Jul 8 20:40:48 2025
Status: finished
Duration: 0:00:01
Total to scrub: 2.00GiB
Rate: 2.00GiB/s
Error summary: no errors found
The original run takes less than 1 seconds, making the scrub rate
calculation very unreliable, no wonder the speed limit is not able to
properly work.
[FIX]
Instead of using fixed 2GiB file size, let the test create a filler for
4 seconds with direct IO, this would more or less ensure the scrub will
take 4 seconds to run.
With 4 seconds as run time, the scrub rate can be calculated more or
less reliably.
Furthermore since btrfs-progs currently only reports scrub duration in
seconds, to prevent problems due to 1 second difference, enlarge the
tolerance to +/- 25%, to be extra safe.
On my testing VM, the result looks like this:
Starting scrub on devid 1
scrub done for b542bdfb-7be4-44b3-add0-ad3621927e2b
Scrub started: Fri Jul 11 09:13:31 2025
Status: finished
Duration: 0:00:04
Total to scrub: 2.72GiB
Rate: 696.62MiB/s
Error summary: no errors found
Starting scrub on devid 1
scrub done for b542bdfb-7be4-44b3-add0-ad3621927e2b
Scrub started: Fri Jul 11 09:13:35 2025
Status: finished
Duration: 0:00:08
Total to scrub: 2.72GiB
Rate: 348.31MiB/s
Error summary: no errors found
However this exposed a new failure mode, that if the storage is too
fast, like the original report, that the initial 4 seconds write can
fill the fs and exit early.
In that case we have no other solution but skipping the test case.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 10 Jul 2025 17:03:43 +0000 (18:03 +0100)]
generic: test overwriting file with mmap on a full filesystem
Test that overwriting a file with mmap when the filesystem has no more
space available for data allocation works. The motivation here is to check
that NOCOW mode of a COW filesystem (such as btrfs) works as expected.
This currently fails with btrfs but it's fixed by a kernel patch that has
the subject:
btrfs: fix -ENOSPC mmap write failure on NOCOW files/extents
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
[BUG]
With the incoming btrfs shutdown ioctl/remove_bdev callback support,
btrfs can be tested with the shutdown group.
But test case generic/050 still fails on btrfs with shutdown support:
generic/050 1s ... - output mismatch (see /home/adam/xfstests/results//generic/050.out.bad)
--- tests/generic/050.out 2022-05-11 11:25:30.763333331 +0930
+++ /home/adam/xfstests/results//generic/050.out.bad 2025-06-30 10:22:21.752068622 +0930
@@ -13,9 +13,7 @@
setting device read-only
mounting filesystem that needs recovery on a read-only device:
mount: device write-protected, mounting read-only
-mount: cannot mount device read-only
unmounting read-only filesystem
-umount: SCRATCH_DEV: not mounted
mounting filesystem with -o norecovery on a read-only device:
...
(Run 'diff -u /home/adam/xfstests/tests/generic/050.out /home/adam/xfstests/results//generic/050.out.bad' to see the entire diff)
Ran: generic/050
[CAUSE]
The test case generic/050 has several different golden output depending
on the fs features.
For fses which requires data write (e.g. replay the journal) during
mount, mounting a read-only block device should fail.
And that is the default golden output.
However for btrfs, although it has something similar to a journal, aka
log tree, it's not the traditional journal which is used to protect
metadata update.
The log tree of btrfs is mostly for speeding up fsync() without syncing
the full fs.
This means several things are different with btrfs:
- Regular metadata update won't cause dirty log tree
The workload here is just touching several files, which will not cause
the creation of btrfs log tree.
And the metadata consistency is protected by metadata COW, not
journal.
- FLUSHLOG shutdown flag will cause btrfs to commit the current
transaction
And above new files are recorded in the current transaction, meaning
those new files will be fully written by a FLUSHLOG shutdown.
This means, unlike fses using traditional journals, touching files then
shutdown with FLUSHLOG will not cause any dirty log tree.
This makes btrfs acts like it doesn't support metadata journaling, at
least for this particular test case.
[FIX]
Since the workload here will not cause btrfs to generate a log tree,
meaning after the shutdown, the fs can still be mounted RO even the
block device is read-only.
So here we have to make an exception for btrfs, that it has to go
through the "nojournal" feature.
Zorro Lang [Sun, 22 Jun 2025 20:39:47 +0000 (04:39 +0800)]
common/rc: _add_dmesg_filter returns when RESULT_DIR is null
I always hit below error on a system with readonly rootfs:
++ _xfs_prepare_for_eio_shutdown /dev/loop0
...
++ _add_dmesg_filter 'Internal error'
++ local 'regexp=Internal error'
++ local filter_file=/dmesg_filter
++ '[' '!' -e /dmesg_filter ']'
++ echo 'Internal error'
./common/rc: line 4716: /dmesg_filter: Read-only file system
The RESULT_DIR is null, due to xfstests/check calls _test_mount and
_scratch_mount before RESULT_DIR creation. And _test_mount does
_prepare_for_eio_shutdown -> _xfs_prepare_for_eio_shutdown ->
_add_dmesg_filter "Internal error" when RESULT_DIR is null.
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 21 May 2025 22:41:20 +0000 (15:41 -0700)]
xfs/259: drop the 512-byte fsblock logic from this test
V5 filesystems do not support 512-byte fsblocks, and mkfs.xfs has long
defaulted to V5 filesystems. Drop the 512 from the test loops, which
means we can get rid of all the _fs_has_crcs logic. As a further
cleanup, use the truncate -s command to create the sparse file instead
of dd since even RHEL7 supports the -s switch.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 21 May 2025 22:41:04 +0000 (15:41 -0700)]
xfs/273: fix test for internal zoned filesystems
For XFS filesystems with internal zoned sections, fsmap reports a u32
cookie for the device instead of an actual major/minor. Adjust the test
accordingly.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Sat, 24 May 2025 03:57:14 +0000 (11:57 +0800)]
fstests: check: fix unset seqres in run_section()
While testing, I saw that ".full" is created by _scratch_unmount(), called here:
725 function run_section()
::
815 if [ ! -z "$SCRATCH_DEV" ]; then
816 _scratch_unmount 2> /dev/null
817 # call the overridden mkfs - make sure the FS is built
Ensure seqres is set early in run_section() as a fix.
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 26 Jun 2025 00:27:35 +0000 (17:27 -0700)]
xfs: more multi-block atomic writes tests
Add xfs specific tests for realtime volumes and error recovery.
The first test validates multi-block atomic writes on a realtime file. We
perform basic atomic writes operations within the advertised sizes and ensure
that atomic writes will fail outside of these bounds. The hardware used in this
test is not required to support atomic writes.
The second test verifies that a large atomic write can complete after a crash.
The error is injected while attempting to free an extent. We ensure that this
error occurs by first creating a heavily fragmented filesystem. After recovery,
we check that the write completes successfully.
The third test verifies that a large atomic write on a reflinked file can
complete after a crash. We start with two files that share the same data and
inject an error while attempting to perform a write on one of the files. After
recovery, we verify that these files now contain different data, indicating
that the write has succeeded.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 26 Jun 2025 00:27:34 +0000 (17:27 -0700)]
generic: various atomic write tests with hardware and scsi_debug
Simple tests of various atomic write requests and a (simulated) hardware
device.
The first test performs basic multi-block atomic writes on a scsi_debug device
with atomic writes enabled. We test all advertised sizes between the atomic
write unit min and max. We also ensure that the write fails when expected, such
as when attempting buffered io or unaligned directio.
The second test is similar to the one above, except that it verifies multi-block
atomic writes on actual hardware instead of simulated hardware. The device used
in this test is not required to support atomic writes.
The final two tests ensure multi-block atomic writes can be performed on various
interweaved mappings, including written, mapped, hole, and unwritten. We also
test large atomic writes on a heavily fragmented filesystem. These tests are
separated into reflink (shared) and non-reflink tests.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Catherine Hoang [Thu, 26 Jun 2025 00:27:33 +0000 (17:27 -0700)]
common/atomicwrites: add helper for multi block atomic writes
Add a helper to check that we can perform multi block atomic writes. We will
use this in the following patches that add testing for large atomic writes.
This helper will prevent these tests from running on kernels that only support
single block atomic writes.
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Leah Rumancik [Wed, 25 Jun 2025 21:20:22 +0000 (14:20 -0700)]
common/rc: add repair fsck flag -f for ext4
There is a descrepancy between the fsck flags for ext4 during
filesystem repair and filesystem checking which causes occasional test
failures. In particular, _check_generic_filesystems uses -f for force
checking, but _repair_scratch_fs does not. In some tests, such as
generic/441, we sometimes exit fsck repair early with the filesystem
being deemed "clean" but then _check_generic_filesystems finds issues
during the forced full check. Bringing these flags in sync fixes the
flakes.
Signed-off-by: Leah Rumancik <leah.rumancik@gmail.com> Reviewed-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Miklos Szeredi [Mon, 9 Jun 2025 15:19:15 +0000 (17:19 +0200)]
overlay: add tests for data-only redirect with userxattr
New kernel feature (target release is v6.16) allows data-only redirect to
be enabled without metacopy and redirect_dir turned on. This works with or
without verity enabled.
Tests are done with the userxattr option, to verify that it will work in a
user namespace.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 9 Jun 2025 15:19:14 +0000 (17:19 +0200)]
fstests: add helper _require_xfs_io_shutdown
Requirements for tests that shutdown fs using "xfs_io -c shutdown".
The requirements are stricter than the requirement for tests that
shutdown fs using _scratch_shutdown helper.
Generally, with overlay fs, tests can do _scratch_shutdown, but not
xfs_io -c shutdown.
Encode this stricter requirement in helper _require_xfs_io_shutdown
and use it in test generic/623, to express that it cannot run on
overalyfs.
Reported-by: André Almeida <andrealmeid@igalia.com> Link: https://lore.kernel.org/linux-fsdevel/20250521-ovl_ro-v1-1-2350b1493d94@igalia.com/ Signed-off-by: Amir Goldstein <amir73il@gmail.com> Tested-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 9 Jun 2025 15:19:13 +0000 (17:19 +0200)]
fstests: add helper _scratch_shutdown_and_syncfs
Test xfs/546 has to chain syncfs after shutdown and cannot
use the _scratch_shutdown helper, because after shutdown a fd
cannot be opened to execute syncfs on.
The xfs_io command of chaining syncfs after shutdown is rather
more complex to execute in the derived overlayfs test overlay/087.
Add a helper to abstract this complexity from test writers.
Add a _require statement to match.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
The test specifically requires metadata directory functionality, so make
it dependent on that as otherwise it fails on kernels older than v6.13
that do not implement the feature.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Daniel Gomez [Wed, 18 Jun 2025 13:00:12 +0000 (15:00 +0200)]
generic/551: prevent OOM when running on tmpfs with low memory
Running generic/551 on a tmpfs filesystem with less than 10 GB (ish)
of RAM can lead to the system running out of memory, triggering the
kernel's OOM killer and terminating the aio-dio-write-v process.
Fix generic/551 by substracting the amount of available memory allocated
for the tmpfs scratch device to the total available free memory.
Reported-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 13 Jun 2025 13:05:08 +0000 (14:05 +0100)]
btrfs/300: set umask to avoid failure on systems with a different umask
The test is assuming a umask of 0022, which is the default on many Linux
setups, but often we can find other umasks such as in recent Debian box
I have where the default umask is 0002, and this makes the test fail like
this:
The mismatch with the golden output is because the test is expecting an
umask of 0022 where the write bit is not set for owner group, but with
a umask of 0002 for example, the write bit is set for the owner group.
Fix this by making the test set a umask of 0022, so that it works for
any system or user defined umask.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/740: move checking for a scratch device up
Commit 3ae8a19f97d0 ("generic/740: enable by default") moved these checks
down accidentally. Move them back up to make the test exit gracefully
when no scratch device is provided.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Wed, 28 May 2025 11:42:20 +0000 (12:42 +0100)]
generic/032: fix failure due to attempt to wait for non-child process
Running generic/032 can sporadically fail like this:
generic/032 11s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/032.out.bad)
--- tests/generic/032.out 2023-03-02 21:47:53.884609618 +0000
+++ /home/fdmanana/git/hub/xfstests/results//generic/032.out.bad 2025-05-28 10:39:34.549499493 +0100
@@ -1,5 +1,6 @@
QA output created by 032
100 iterations
+/home/fdmanana/git/hub/xfstests/tests/generic/032: line 90: wait: pid 3708239 is not a child of this shell
000000 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd >................<
*
100000
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/generic/032.out /home/fdmanana/git/h
This is because we are attempting to wait for a process that is not a
child process of the test process and it's instead a child of a process
spawned by the test.
To make sure that after we kill the process running _syncloop() there
isn't any xfs_io process still running syncfs, add instead a trap to
to _syncloop() that waits for xfs_io to finish before the process running
that function exits.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
src/fill2: fix segfault during fopen error cleanup
When fill2 fails to open the output file (e.g. due to ENOSPC), it jumps
into the cleanup code where it attempts to call fclose, and this causes
a segfault within the glibc fclose code as it attempts to deref a null
pointer.
Fix it by conditionally calling fclose on the file pointer only when
non-null.
This is consistently reproducible with xfs/041.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Fri, 13 Jun 2025 13:52:10 +0000 (21:52 +0800)]
generic/633: add _require_chown
For file systems that do not support chown, such as exfat,
running this test does not make sense and should be skipped.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Fri, 6 Jun 2025 10:28:55 +0000 (18:28 +0800)]
generic/622: fix for exfat
After commit(f761fcdd289d exfat: Implement sops->shutdown and
ioctl), shutdown is supported by exfat, this test can be run, but
fails because exfat has a 2 second granularity for access_time
and no timestamps for metadata changes.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hans Holmberg [Mon, 9 Jun 2025 11:03:54 +0000 (11:03 +0000)]
ext4/002: make generic to support xfs
xfs supports separate log devices and as this test now passes, share
it by turning it into a generic test.
This should not result in a new failure for other file systems as only
ext2/ext3/ext4 and xfs supports mkfs with SCRATCH_LOGDEVs.
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hans Holmberg [Mon, 9 Jun 2025 11:03:53 +0000 (11:03 +0000)]
xfs: add mount test for read only rt devices
Make sure that we can mount rt devices read-only if them themselves
are marked as read-only.
Also make sure that rw re-mounts are not allowed if the device is
marked as read-only.
Based on generic/050.
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Wed, 4 Jun 2025 23:55:24 +0000 (09:25 +0930)]
fstests: generic/741: make cleanup to handle test failure properly
[BUG]
When I was tinkering the bdev open holder parameter, it caused a bug
that it no longer rejects mounting the underlying device of a
device-mapper.
And the test case properly detects the regression:
generic/741 1s ... umount: /mnt/test: target is busy.
_check_btrfs_filesystem: filesystem on /dev/mapper/test-test is inconsistent
(see /home/adam/xfstests/results//generic/741.full for details)
Trying to repair broken TEST_DEV file system
_check_btrfs_filesystem: filesystem on /dev/mapper/test-scratch1 is inconsistent
(see /home/adam/xfstests/results//generic/741.full for details)
- output mismatch (see /home/adam/xfstests/results//generic/741.out.bad)
--- tests/generic/741.out 2024-04-06 08:10:44.773333344 +1030
+++ /home/adam/xfstests/results//generic/741.out.bad 2025-06-05 09:18:03.675049206 +0930
@@ -1,3 +1,2 @@
QA output created by 741
-mount: TEST_DIR/extra_mnt: SCRATCH_DEV already mounted or mount point busy
-mount: TEST_DIR/extra_mnt: SCRATCH_DEV already mounted or mount point busy
+rm: cannot remove '/mnt/test/extra_mnt': Device or resource busy
...
(Run 'diff -u /home/adam/xfstests/tests/generic/741.out /home/adam/xfstests/results//generic/741.out.bad' to see the entire diff)
The problem is, all later test will fail, because the $SCRATCH_DEV is
still mounted at $extra_mnt:
TEST_DEV=/dev/mapper/test-test is mounted but not on TEST_DIR=/mnt/test - aborting
Already mounted result:
/dev/mapper/test-test /mnt/test /dev/mapper/test-test /mnt/test
[CAUSE]
The test case itself is doing two expected-to-fail mounts, but the
cleanup function is only doing unmount once, if the mount succeeded
unexpectedly, the $SCRATCH_DEV will be mounted at $extra_mnt forever.
[ENHANCEMENT]
To avoid screwing up later test cases, do the $extra_mnt cleanup twice
to handle the unexpected mount success.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Tue, 3 Jun 2025 10:07:45 +0000 (12:07 +0200)]
generic/699: fix failure with MOUNT_OPTIONS
generic/699 uses overalyfs helper _overlay_mount_dirs, which is meant to
be used by overlayfs tests, where MOUNT_OPTIONS refer to overalyfs mount
options.
Using this helper from a generic test when FSTYP is not overlay is
causing undesired results. For example, when MOUNT_OPTIONS is defined
and includes a mount option not supported by overalyfs (e.g. 'acl'),
the test is notrun because of:
commit f5661920 ("generic: add missed _require_idmapped_mounts check")
wrongly adds _require_idmapped_mounts to tests that do not require
idmapped mounts support.
The added _require_idmapped_mounts in test generic/633 goes against
commit d8dee122 ("idmapped-mounts: always run generic vfs tests")
that intentionally removed this requirement from the generic tests.
The added _require_idmapped_mounts in tests generic/69{6,7} causes
those tests not to run with overlayfs, which does not support idmapped
mounts. However, those tests are regression tests to kernel commit 1639a49ccdce ("fs: move S_ISGID stripping into the vfs_*() helpers")
which is documented as also solving a correction issue with overlayfs,
so removing this test converage is very much undesired.
Remove the incorrectly added _require_idmapped_mounts checks.
Also fix the log in _require_idmapped_mounts to say that
"idmapped mounts not support by $FSTYP", which is what the helper
checks instead of "vfstests not support by $FSTYP" which is incorrect.
Cc: Yang Xu <xuyang2018.jy@fujitsu.com> Cc: Anthony Iliopoulos <ailiop@suse.com> Cc: David Disseldorp <ddiss@suse.de> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Tue, 3 Jun 2025 10:07:42 +0000 (12:07 +0200)]
generic/604: do not run with overlayfs
Overlayfs does not allow mounting over again with the same layers
until umount is fully completed, so is not appropriate for this test
which tries to mount in parallel to umount.
This is manifested as the test failure below when overlayfs strict mount
checks are enabled by enabling the index feature:
$ echo Y > /sys/module/overlay/parameters/index
...
+mount: /vdf/ovl-mnt: /vdf already mounted or mount point busy.
+ dmesg(1) may have more information after failed mount system call.
+mount /vdf /vdf/ovl-mnt failed
Opt-out of this test with overlayfs and remove the hacks that were placed
by commit 06cee932 ("generic/604: Fix for overlayfs") to make the test pass
with overlayfs in the first place.
Tested-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Tue, 3 Jun 2025 10:07:41 +0000 (12:07 +0200)]
overlay: fix regression in _repair_overlay_scratch_fs
_repair_overlay_scratch_fs assumed that the base fs is mounted.
This was a wrong assumption to make, and that was exposed by commit 4c6bc456 ("fstests: clean up mount and unmount operations") that
converted open coded umount in generic/332 to _scratch_unmount.
After this change, there errors were observed when running generic/332
if fsck.overlay is installed:
Check for damage
+fsck.overlay:[Error]: Faile to resolve upperdir:/vdf/ovl-upper:
No such file or directory
+fsck.overlay failed, err=8
+umount: /vdf: not mounted.
Fix this by making sure that base fs is mounted before running the
layers check and fix test generic/330 to conform with the umount
conversion patch.
Fixes: 4c6bc456 ("fstests: clean up mount and unmount operations") Tested-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 23 May 2025 17:20:50 +0000 (18:20 +0100)]
fsstress: print syncfs() return value in verbose mode
We aren't logging the syncfs() return value in case we are running in
verbose mode, which is useful and it would help me immediately figuring
out it was failing in a problem I was debugging with btrfs.
So log its return value, just like we do for every other fsstress command.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chunhai Guo [Mon, 26 May 2025 08:03:23 +0000 (02:03 -0600)]
f2fs/014: test for missing 'trimmed' flag issue
This is a regression test case to verify whether the CP_TRIMMED_FLAG is
properly set after performing the following steps:
1. mount the f2fs filesystem
2. create a file, write data to it, then delete the file
3. unmount the filesystem
4. verify that the 'trimmed' flag is set in the checkpoint state
We should apply the commit ("f2fs: fix missing discard for active
segments") to resolve the issue where the 'trimmed' flag is missing.
Signed-off-by: Chunhai Guo <guochunhai@vivo.com> Reviewed-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jan Prusakowski [Fri, 30 May 2025 09:23:49 +0000 (09:23 +0000)]
f2fs/004: avoid race condition in test
In current implementation the atomic write may not start before
the direct write and the test fails.
The patch adds a delay after starting the atomic write process
so it has a chance to actually start wrtiting data and set the
internal state of the file correctly.
Signed-off-by: Jan Prusakowski <jprusakowski@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 29 May 2025 11:33:13 +0000 (12:33 +0100)]
generic/094: fix test ignoring failures
The test is ignoring failures completely:
1) If mounting the scratch device fails it redirects both stdout and
stderr to /dev/null, so it gets unnoticed and the test runs against
a different fs than expected (in my test environment $SCRATCH_MNT
points to a directory in an ext4 fs for example but I want to test
btrfs);
2) We are redirecting the stdout and stderr of fiemap-tester to the
$seqres.full file, so if it fails it gets completely unnoticed and
the test succeeds.
For the first issue fix this by not even using the scratch filesystem and
use instead the test filesystem, since the test creates a 2M file which
is small enough.
For the second issue simply don't redirect the stdout and stderr, so that
if the test program fails it causes a mismatch with the golden output,
making the test fail.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Wed, 28 May 2025 09:15:29 +0000 (17:15 +0800)]
generic/645: add _require_chown
This test uses chown to set GID and UID, which requires chown
support, so add _require_chown to check for chown support.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Wed, 28 May 2025 09:15:28 +0000 (17:15 +0800)]
generic/730: add _require_scratch_shutdown
Before testing for shutdown, check whether the file system
supports it with _require_scratch_shutdown.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Wed, 28 May 2025 09:15:27 +0000 (17:15 +0800)]
generic/755: add _require_hardlinks
This test is used to test whether the ctime of the original file
changes after deleting its hard link, which requires hardlink
support, so add _require_hardlinks to check for hardlink support.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Wed, 28 May 2025 09:15:26 +0000 (17:15 +0800)]
generic/754: add _require_symlinks
This test tests whether xattrs can be added to a symbolic link,
which requires symlink support, so add _require_symlinks to check
for symlink support.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Wed, 28 May 2025 09:15:25 +0000 (17:15 +0800)]
generic/656: add _require_chown
This test uses chown to set GID and UID, which requires chown
support, so add _require_chown to check for chown support.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Wed, 28 May 2025 09:15:24 +0000 (17:15 +0800)]
generic/696: add _require_chmod
This test uses chmod to set the S_ISGID bit, which requires chmod
support, so add _require_chmod to check for chmod support.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Friendy Su <friendy.su@sony.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Fix this function to call _notrun whenever something fails. If we can't
figure out the atomic write geometry, then we haven't satisfied the
preconditions for the test.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 2 Jun 2025 19:22:13 +0000 (12:22 -0700)]
common/atomicwrites: adjust a few more things
Always export STATX_WRITE_ATOMIC so anyone can use it, make the "cp
reflink" logic work for any filesystem, not just xfs, and create a
separate helper to check that the necessary xfs_io support is present.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 2 Jun 2025 19:22:11 +0000 (12:22 -0700)]
generic/765: adjust various things
Fix some bugs when detecting the atomic write geometry, record what
atomic write geometry we're testing each time through the loop, and
create a group for atomic writes tests.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 2 Jun 2025 19:22:10 +0000 (12:22 -0700)]
generic/765: fix a few issues
Fix a few bugs in the single block atomic writes test, such as not requiring
directio, using the page size for the ext4 max bsize, and making sure we check
the max atomic write size.
Cc: ritesh.list@gmail.com Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Fri, 9 May 2025 17:04:56 +0000 (19:04 +0200)]
open_by_handle: add a test for connectable file handles
This is a variant of generic/477 with connectable file handles.
This test uses load and store of file handles from a temp file to test
decoding connectable file handles after cycle mount and after renames.
Decoding connectable file handles after being moved to a new parent
is expected to fail on some filesystems, but not on filesystems that
do not really get unmounted in mount cycle like tmpfs, so skip this test.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Tue, 13 May 2025 23:03:01 +0000 (08:33 +0930)]
fstests: btrfs/020: use device pool to avoid busy TEST_DEV
[BUG]
There is an internal report about btrfs/020 failure, the 020.full looks
like this:
ERROR: ioctl(DEV_REPLACE_START) failed on "/opt/test/020.5968.mnt": Read-only file system
Performing full device TRIM /dev/loop8 (256.00MiB) ...
_check_btrfs_filesystem: filesystem on /dev/loop0 is inconsistent
*** fsck.btrfs output ***
ERROR: /dev/loop0 is currently mounted, use --force if you really intend to check the filesystem
Opening filesystem to check...
*** end fsck.btrfs output
*** mount output ***
[...]
/dev/loop0 on /opt/test type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)
*** end mount output
[CAUSE]
Unfortunately I can not reproduce the situation here, but it looks like
by somehow we didn't unmount the TEST_DEV before checking it.
This may or may not be caused by the fact we're using loop back devices
on TEST_MNT.
[FIX]
For this particluar test case, we really do not need to use TEST_MNT and
create complex loopback devices.
We can just ask for 3 devices from the device pool, use 2 for the raid1
fs, and then use the spare one for dev replace.
This should greately simplify the test case setup and cleanup, thus
avoid the above busy TEST_DEV and false test failure.
Furthermore use the golden output to match the error message, and since
we're here also handle a bug in btrfs-progs where the error message is
incorrectly split into two lines.
btrfs/220 6s ... - output mismatch (see /home/adam/xfstests/results//btrfs/220.out.bad)
--- tests/btrfs/220.out 2022-05-11 11:25:30.749999997 +0930
+++ /home/adam/xfstests/results//btrfs/220.out.bad 2025-05-13 16:26:18.068521503 +0930
@@ -1,2 +1,4 @@
QA output created by 220
+mount warning:
+ * btrfs: Deprecated parameter 'nologreplay'
Silence is golden
...
(Run 'diff -u /home/adam/xfstests/tests/btrfs/220.out /home/adam/xfstests/results//btrfs/220.out.bad' to see the entire diff)
Ran: btrfs/220
Failures: btrfs/220
Failed 1 of 1 tests
[CAUSE]
The newer mount command provides the extra ability to show warning during
mount.
Although btrfs still supports "nologreplay" mount option to keep
consistency with other filesystems, we will output a warning and
encourage users to use "rescue=nologreplay" instead.
During "nologreplay" mount option test, normally we will mount use
the newer "rescue=nologreplay" mount option if the kernel supports.
But the following two call sites are still unconditionally utilizing
the deprecated "nologreplay" mount option directly:
- Expected failure when using nologreplay and rw mount
- Mount option verification that "nologreplay" is converted to
"rescue=nologreplay"
The second call site caused the above mount warning message and fail the
test case.
[FIX]
If the kernel supports "rescue=nologreplay" we should not utilized
"nologreplay" at all.
This will avoid the mount warning on the deprecated and discouraged
"nologreplay" mount option.
Now that kernel commit 'b0c26f479926 ("btrfs: zoned: return EIO on RAID1 block
group write pointer mismatch")' is merged, add git commit ID to fstests
btrfs/335 and also add the test to the auto group.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / xfstests-dev.git / log