ext4: Test atomic writes allocation and write codepaths with bigalloc
This test does a parallel RWF_ATOMIC IO on a multiple truncated files in
a small FS. The idea is to stress ext4 allocator to ensure we are able
to handle low space scenarios correctly with atomic writes. We brute
force this for different blocksize and clustersizes and after each
iteration we ensure the data was not torn or corrupted using fio crc
verification.
Note that in this test we use overlapping atomic writes of same io size.
Although serializing racing writes is not guaranteed for RWF_ATOMIC,
NVMe and SCSI provide this guarantee as an inseparable feature to
power-fail atomicity. Keeping the iosize as same also ensures that ext4
doesn't tear the write due to racing ioend unwritten conversion.
The value of this test is that we make sure the RWF_ATOMIC is handled
correctly by ext4 as well as test that the block layer doesn't split or
only generate multiple bios for an atomic write.
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
ext4: Test atomic write and ioend codepaths with bigalloc
This test does a lot of parallel RWF_ATOMIC IO on a preallocated file to
stress the write and end-io unwritten conversion code paths. We brute
force this for different blocksize and clustersizes and after each
iteration we ensure the data was not torn or corrupted using fio crc
verification.
Note that in this test we use overlapping atomic writes of same io size.
Although serializing racing writes is not guaranteed for RWF_ATOMIC,
NVMe and SCSI provide this guarantee as an inseparable feature to
power-fail atomicity. Keeping the iosize as same also ensures that ext4
doesn't tear the write due to racing ioend unwritten conversion.
The value of this test is that we make sure the RWF_ATOMIC is handled
correctly by ext4 as well as test that the block layer doesn't split or
only generate multiple bios for an atomic write.
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic: Add sudden shutdown tests for multi block atomic writes
This test is intended to ensure that multi blocks atomic writes
maintain atomic guarantees across sudden FS shutdowns.
The way we work is that we lay out a file with random mix of written,
unwritten and hole extents. Then we start performing atomic writes
sequentially on the file while we parallelly shutdown the FS. Then we
note the last offset where the atomic write happened just before shut
down and then make sure blocks around it either have completely old
data or completely new data, ie the write was not torn during shutdown.
We repeat the same with completely written, completely unwritten and completely
empty file to ensure these cases are not torn either. Finally, we have a
similar test for append atomic writes
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
This adds various atomic write multi-fsblock stress tests
with mixed mappings and O_SYNC, to ensure the data and metadata
is atomically persisted even if there is a shutdown.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic: Add atomic write test using fio verify on file mixed mappings
This test uses fio to first create a file with mixed mappings. Then it
does atomic writes using aio dio with parallel jobs to the same file
with mixed mappings. Finally, we perform a fio verify step to ensure
there is no data corruption or torn write.
The aim is to stress the FS block allocation and extent handling logic
to ensure it handles mixed mappings with RWF_ATOMIC correctly without
tearing or losing data.
Avoid doing overlapping parallel atomic writes because it might give
unexpected results. Use offset_increment=, size= fio options to achieve
this behavior.
Co-developed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic: Add atomic write test using fio crc check verifier
This adds atomic write test using fio based on it's crc check verifier.
fio adds a crc header for each data block, which is verified later to
ensure there is no data corruption or torn write.
This test essentially does a lot of parallel RWF_ATOMIC IO on a
preallocated file to stress the write and end-io unwritten conversion
code paths. The idea is to increase code coverage to ensure RWF_ATOMIC
hasn't introduced any issues.
Avoid doing overlapping parallel atomic writes because it might give
unexpected results. Use offset_increment=, size= fio options to achieve
this behavior.
Co-developed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
common/rc: Add a helper to run fsx on a given file
Currently run_fsx is hardcoded to run on a file in $TEST_DIR.
Add a helper _run_fsx_on_file so that we can run fsx on any
given file including in $SCRATCH_MNT. Also, refactor _run_fsx
to use this helper.
No functional change is intended in this patch.
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
The main motivation of adding this function on top of _require_fio is
that there has been a case in fio where atomic= option was added but
later it was changed to noop since kernel didn't yet have support for
atomic writes. It was then again utilized to do atomic writes in a later
version, once kernel got the support. Due to this there is a point in
fio where _require_fio w/ atomic=1 will succeed even though it would
not be doing atomic writes.
Hence, add an internal helper __require_fio_version to require specific
versions of fio to work past such issues. Further, add the high level
_require_fio_atomic_writes helper which tests can use to ensure fio
has the right version for atomic writes.
Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Many programs open code these functionalities so add it as a generic helper
in common/rc
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: John Garry <john.g.gary@oracle.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jan Prusakowski [Mon, 6 Oct 2025 10:07:13 +0000 (12:07 +0200)]
f2fs/009: Add delay after killing socket tool
When running the test in a VM on a host with all CPUs busy, the kill command
returns before socket tool shuts down. This prevents unmounting the
scratch, causing the test to fail.
The added sleep ensures that the socket tool closes before the next test steps.
Signed-off-by: Jan Prusakowski <jprusakowski@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jan Prusakowski [Mon, 6 Oct 2025 09:58:13 +0000 (11:58 +0200)]
common/encrypt: Explicitly set the test file to uncompressed
verify_ciphertext_for_encryption_policy() checks if encryption works
correctly by reading encrypted file's contents directly from a block device and
comparing it to a known good ciphertext.
This, however, won't work if the test file is also compressed. So this patch
adds a check if a test file is compressed and disables its compression in this
case.
Signed-off-by: Jan Prusakowski <jprusakowski@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Ojaswin Mujoo [Sat, 11 Oct 2025 13:47:08 +0000 (19:17 +0530)]
ext4/060: Skip for dax devices on non-4k page sizes
This test tries to trigger an ext4 corruption by resizing past the
meta_bg size (8GB on 4k blocksize) in ext4. Since the test is sensistive
to the size and FS layout it hardcodes the 4kb blocksize ignoring user's
$MKFS_OPTIONS. While this is okay for most cases it fails for dax based
filesystems where system pagesize is non-4k.
One way to work past this is to make the test blocksize agnostic, but
since we still need the disk to be as big as the meta_bg size, this
means for blocksize=64kb filesystems we need a scratch disk of ~4TB
which is not feasible.
Hence, just skip the test if fsdax is used in a non-4k page size system.
The reason is that, some of the subtests are written with 4k blocksize
in mind. Fix the test by making the offsets and sizes to multiples of
64k so that it becomes compatible/aligned with all supported block sizes.
Reported-by: Disha Goel <disgoel@linux.ibm.com> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/200: Make the test compatible with all supported block sizes
This test fails on 64k block size with the following error:
At snapshot incr
OK
OK
+File foo does not have 2 shared extents in the base snapshot
+/mnt/scratch/base/foo:
+ 0: [0..255]: 26624..26879
+File foo does not have 2 shared extents in the incr snapshot
So, basically after btrfs receive, the file /mnt/scratch/base/foo
doesn't have any shared extents in the base snapshot.
The reason is that during btrfs send, the extents are not cloned
and instead they are written.
The following condition is responsible for the above behavior
in function clone_range():
/*
* Prevent cloning from a zero offset with a length matching the sector
* size because in some scenarios this will make the receiver fail.
*
* For example, if in the source filesystem the extent at offset 0
* has a length of sectorsize and it was written using direct IO, then
* it can never be an inline extent (even if compression is enabled).
* Then this extent can be cloned in the original filesystem to a non
* zero file offset, but it may not be possible to clone in the
* destination filesystem because it can be inlined due to compression
* on the destination filesystem (as the receiver's write operations are
* always done using buffered IO). The same happens when the original
* filesystem does not have compression enabled but the destination
* filesystem has.
*/
if (clone_root->offset == 0 &&
len == sctx->send_root->fs_info->sectorsize)
return send_extent_data(sctx, dst_path, offset, len);
Since we are cloning from the first half [0 to 64k), clone_root->offset = 0
and len = 64k which is the sectorsize (sctx->send_root->fs_info->sectorsize).
Fix this by increasing the file size and offsets to 128k so that
len == sctx->send_root->fs_info->sectorsize is not true.
Reported-by: Disha Goel <disgoel@linux.ibm.com> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/562: Make test compatible with block sizes till 64k
This test fails with 64k sector size in btrfs. The reason for
this is the need for additional space because of COW. When
the reflink/clone of file bar into file foo is done, there
is no additional space left for COW - the reason is that the
metadata space usage is much higher with 64k node size.
In order to verify this, I instrumented the test script and
disabled COW for file foo and bar and the test passes in 64k
(and runs faster too).
With 64k sector and node size (COW enabled)
After pwriting foo and bar and before filling up the fs
Filesystem Size Used Avail Use% Mounted on
/dev/loop1 512M 324M 3.0M 100% /mnt1/scratch
After filling up the fs
Filesystem Size Used Avail Use% Mounted on
/dev/loop1 512M 441M 3.0M 100% /mnt1/scratch
With 64k sector and node size (COW disabled)
After pwriting foo and bar and before filling up the fs
Filesystem Size Used Avail Use% Mounted on
/dev/loop1 512M 224M 231M 50% /mnt1/scratch
After filling up the fs
Filesystem Size Used Avail Use% Mounted on
/dev/loop1 512M 424M 31M 94% /mnt1/scratch
As we can see, with COW, the fs is completely full after
filling up the fs but with COW disabled, we have some
space left.
Fix this by increasing the fs size to 590M so that even with
64k node size and COW enabled, reflink has enough space to
continue.
Reported-by: Disha Goel <disgoel@linux.ibm.com> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
With addition of file_getattr() and file_setattr(), xfs_quota now can
set project ID on filesystem inodes behind special files. Previously,
quota reporting didn't count inodes of special files created before
project initialization. Only new inodes had project ID set.
Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
This programs uses newly introduced file_getattr and file_setattr
syscalls. This program is partially a test of invalid options. This will
be used further in the test.
Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Please note that, btrfs bs > ps is still under development.
This is only an early run to expose false alerts.
[CAUSE]
The test case btrfs/192 requires 4K nodesize to bump up tree size, and
btrfs/30[456] all requires 4K block size as the workload is designed
with that.
However if the QA runner is specify other block size (8K in this case),
it will break the 4K block size assumption of those tests, either
results mkfs failure in btrfs/192, or output difference for
btrfs/30[456].
[FIX]
Just explicitly specify the 4K block size during mkfs.
And since we're here, remove the out-of-date page size check, as btrfs
has subpage block size support for a while.
Instead use a more accurate supported sector size check, this allows the
test to be run on aarch64 with 64K page size.
Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/012 [failed, exit status 1]- output mismatch (see /home/adam/xfstests/results//btrfs/012.out.bad)
--- tests/btrfs/012.out 2024-07-17 16:27:18.790000343 +0930
+++ /home/adam/xfstests/results//btrfs/012.out.bad 2025-09-15 16:32:55.185922173 +0930
@@ -1,7 +1,11 @@
QA output created by 012
+mount: /mnt/scratch: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch1, missing codepage or helper program, or other error.
+ dmesg(1) may have more information after failed mount system call.
+mkdir: cannot create directory '/mnt/scratch/stressdir': File exists
+umount: /mnt/scratch: not mounted.
Checking converted btrfs against the original one:
-OK
...
(Run 'diff -u /home/adam/xfstests/tests/btrfs/012.out /home/adam/xfstests/results//btrfs/012.out.bad' to see the entire diff)
btrfs/136 3s ... - output mismatch (see /home/adam/xfstests/results//btrfs/136.out.bad)
--- tests/btrfs/136.out 2022-05-11 11:25:30.743333331 +0930
+++ /home/adam/xfstests/results//btrfs/136.out.bad 2025-09-19 07:00:00.395280850 +0930
@@ -1,2 +1,10 @@
QA output created by 136
+mount: /mnt/scratch: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch1, missing codepage or helper program, or other error.
+ dmesg(1) may have more information after failed mount system call.
+umount: /mnt/scratch: not mounted.
+mount: /mnt/scratch: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch1, missing codepage or helper program, or other error.
+ dmesg(1) may have more information after failed mount system call.
+umount: /mnt/scratch: not mounted.
...
(Run 'diff -u /home/adam/xfstests/tests/btrfs/136.out /home/adam/xfstests/results//btrfs/136.out.bad' to see the entire diff)
[CAUSE]
Currently ext* doesn't support block size larger than page size, thus
at mkfs time it will output the following warning:
Warning: blocksize 8192 not usable on most systems.
mke2fs 1.47.3 (8-Jul-2025)
Warning: 8192-byte blocks too big for system (max 4096), forced to continue
Furthermore at ext* mount time it will fail with the following dmesg:
EXT4-fs (loop0): bad block size 8192
[FIX]
Check if the mount of the newly created ext* succeeded.
If not and the block size is larger than page size, we know it's some
block size ext* not yet supported, and skip the test case.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
f2fs/022: do sanity check on footer of non inode dnode
This is a regression test:
1. create foo & bar
2. write 8M data to foo
3. use inject.f2fs to inject i_nid[0] of foo w/ ino of bar
4. fpunch in foo w/ specified range
If we haven't applied kernel patch ("f2fs: fix to do sanity check on
node footer for non inode dnode"), f2fs may missed to do sanity check
on corrupted dnode, result in panic or deadloop in step 4).
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>
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>
projects / xfstests-dev.git / log