Ojaswin Mujoo [Wed, 7 Jan 2026 10:37:44 +0000 (16:07 +0530)]
generic/108: fix test hand upon failure to create LV
In case the lvcreate operation fails, we don't catch the error and
proceed as usual. The test then tries to wait for the LV to come up
but it never does, causing a hang.
To fix this:
1. Add a check to ensure SCSI_DEBUG dev is of required size
2. Additionally, fail if there are errors while creating the LV.
Context for completeness:
This was noticed when we accidentally used CONFIG_SCSI_DEBUG=y instead
of =m, causing it to create an 8MB SCSI debug device. This led to the
lvcreate operation to fail with:
Insufficient suitable allocatable extents for logical volume lv_108: 68 more required
However the test never caught this resulting in a hang.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reported-by: Disha Goel <disgoel@linux.ibm.com> Tested-by: Disha Goel <disgoel@linux.ibm.com> Reviewed-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 [Mon, 12 Jan 2026 13:44:09 +0000 (13:44 +0000)]
fsx: add missing -T option to getopt_long()
Currently fsx fails with an invalid argument error when we pass the -T
option (do not use dontcache IO) to it because it's not listed in the
gepopt_long() call.
Fix this and add T to the getopt_long() call.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 6 Jan 2026 12:59:05 +0000 (12:59 +0000)]
btrfs: test power failure after fsync and rename exchanging directories
Test renaming one directory over another one that has a subvolume inside
it and fsync a file in the other directory that was previously renamed.
We want to verify that after a power failure we are able to mount the
filesystem and it has the correct content (all renames visible).
This exercises a bug fixed by the following kernel commit:
7ba0b6461bc4 ("btrfs: always detect conflicting inodes when logging inode refs")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
seed = S
Comparing user usage
+4c4
+< #1000 -- 31476 32000 32000 994 1000 1000
+---
+> #1000 -- 31476 32000 32000 944 1000 1000
...
(Run 'diff -u /share/git/fstests/tests/generic/233.out /share/git/fstests/results//generic/233.out.bad' to see the entire diff)
Ran: generic/233
Failures: generic/233
Failed 1 of 1 tests
Sometimes, generic/233 will fail due to it founds inode count is mismatched
in between quota system and filesystem.
The reason is cgroup v2 implementation will increase inode reference first,
and then, attach it to thread related cgroup writeback structure, once it
needs to switch write owner of target inode, a kernel thread will process
it, and finally release inode reference via evict_inode().
So, sync & drop_cache may not guarantee all inodes being evicted, as cgroup
has one more referenece on inodes during the time.
If inode has not been evicted, dquot inode reference will not be release, it
will lead to inode count mismatch.
Let's add a delay to wait for cgroup switching completion before quota check.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/226 3s ... - output mismatch (see /home/adam/xfstests/results//btrfs/226.out.bad)
--- tests/btrfs/226.out 2024-04-12 14:04:03.080000035 +0930
+++ /home/adam/xfstests/results//btrfs/226.out.bad 2025-12-09 18:46:44.416878799 +1030
@@ -39,14 +39,11 @@
Testing write against prealloc extent at eof
wrote 65536/65536 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 65536
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+pwrite: Resource temporarily unavailable
File after write:
...
(Run 'diff -u /home/adam/xfstests/tests/btrfs/226.out /home/adam/xfstests/results//btrfs/226.out.bad' to see the entire diff)
Ran: btrfs/226
Failures: btrfs/226
Failed 1 of 1 tests
[CAUSE]
For the failure case, the failure is from check_direct_IO(), which find
out that the buffer provided is only aligned to PAGE_SIZE (4K), not to the
fs block size (8K).
The user space can only ensure the allocated memory is contiguous in the
user space, but the user space can not ensure the underlying physical
memory layout, thus depending on the memory allocation situation, the
user space can not always get physically contiguous memory, and fail the
check_direct_IO() call.
After failed check_direct_IO(), we fall back to buffered IO, but since
this particular test case is using RWF_NOWAIT, rejecting buffered IO
fallback, the direct IO failed with -EAGAIN.
[FIX]
Since we can not ensure the physical memory layout for direct IO, just
skip this test case if the fs block size is larger than page size.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/301 42s ... - output mismatch (see /home/adam/xfstests/results//btrfs/301.out.bad)
--- tests/btrfs/301.out 2024-01-02 14:44:11.140000000 +1030
+++ /home/adam/xfstests/results//btrfs/301.out.bad 2025-12-09 19:14:32.057824678 +1030
@@ -1,18 +1,71 @@
QA output created by 301
basic accounting
+subvol 256 mismatched usage 41099264 vs 33964032 (expected data 33554432 expected meta 409600 diff 7135232)
+subvol 256 mismatched usage 175316992 vs 168181760 (expected data 167772160 expected meta 409600 diff 7135232)
+subvol 256 mismatched usage 41099264 vs 33964032 (expected data 33554432 expected meta 409600 diff 7135232)
+subvol 256 mismatched usage 41099264 vs 33964032 (expected data 33554432 expected meta 409600 diff 7135232)
fallocate: Disk quota exceeded
...
(Run 'diff -u /home/adam/xfstests/tests/btrfs/301.out /home/adam/xfstests/results//btrfs/301.out.bad' to see the entire diff)
[CAUSE]
Although the subvolume usage doesn't match the expectation, "btrfs check"
doesn't report any qgroup number mismatch.
This means the qgroup numbers are correct, but our expectation is not.
Upon inspection of the on-disk file extents, there are a lot of file
extents that are partially overwritten.
This means during the fio random writes, there are fs blocks that are
partially written, then written back to the storage, then written again.
This is a symptom of too small IO block size.
The default FIO blocksize is only 4K, and it will result the above
overwrite of the same fs block for 8K fs block size.
[FIX]
Add blocksize option to the fio config, so that we won't have
above over-write behavior which boost the qgroup numbers.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/746 44s ... [failed, exit status 1]- output mismatch (see xfstests-dev/results//generic/746.out.bad)
--- tests/generic/746.out 2024-06-27 13:55:51.286338519 +0930
+++ xfstests-dev/results//generic/746.out.bad 2025-11-28 07:47:17.039827837 +1030
@@ -2,4 +2,4 @@
Generating garbage on loop...done.
Running fstrim...done.
Detecting interesting holes in image...done.
-Comparing holes to the reported space from FS...done.
+Comparing holes to the reported space from FS...Sectors 256-2111 are not marked as free!
...
(Run 'diff -u xfstests-dev/tests/generic/746.out xfstests-dev/results//generic/746.out.bad' to see the entire diff)
[CAUSE]
Sectors [256, 2048) are the from the reserved first 1M free space.
Sectors [2048, 2112) are the leading free space in the chunk tree.
Sectors [2112, 2144) is the first tree block in the chunk tree.
However the reported free sectors from get_free_sectors() looks like this:
2144 10566
10688 11711
...
Note that there should be a free sector range in [2048, 2112) but it's
not reported in get_free_sectors().
The get_free_sectors() call is fs dependent, and for btrfs it's using
parse-extent-tree.awk script to handle the extent tree dump.
The script uses BLOCK_GROUP_ITEM items to detect the beginning of a
block group so that it can calculate the hole between the beginning of a
block group and the first data/metadata item.
However block-group-tree feature moves BLOCK_GROUP_ITEM items to a
dedicated tree, making the existing script unable to parse the free
space at the beginning of a block group.
[FIX]
Introduce a new script, parse-free-space.py, that accepts two tree
dumps:
- block group tree dump
If the fs has block-group-tree feature, it's the block group tree
dump.
Otherwise the regular extent tree dump is enough.
- extent tree dump
The usual extent tree dump.
With a dedicated block group tree dump, the script can correctly handle
the beginning part of free space, no matter if block-group-tree feature
is enabled or not.
And with this parser, the old parse-extent-tree.awk can be retired.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Thu, 4 Dec 2025 04:41:08 +0000 (15:11 +1030)]
fstests: btrfs: add a new test case to verify quick qgroup inherit
[BUG]
There is a bug report that simple quota exposed a bug in the quick
qgroup inherit, that if there is a multi-level qgroup parent
relationship, only the direct parent got updated.
[TEST CASE]
The test case will create the following subvolume and qgroups first:
- A new subvolume at '/subv1'
- Qgroup 1/1
- Qgroup 2/1
And subvolume '/subv1' is assgiend to qgroup 1/1, so 1/1 is the direct
parent.
Then qgroup 1/1 is also assigned to 2/1, so 2/1 is an indirect parent of
subvolume '/subv1'.
Then the trigger part is to creating a snapshot of '/subv1' and also
assigned the new snapshot into qgroup 1/1 during the snapshot creation.
Since 1/1 is the parent of '/subv1' and the new snapshot, and qgroup 1/1
fully owns '/subv1', we can do a quick inherit.
After the triggering part, just finish the test case and the fsck after
the test case should detect any qgroup inconsistency.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs/490: fix failure due to deprecated ikeep mount option
The ikeep mount option has been deprecated as of kernel commit b9a176e54162 ("xfs: remove deprecated mount options"), and after commit 3e7ec343f066 ("xfs: loudly complain about defunct mount options") there
is a warning emitted when testing v5 filesystems.
Fix it by explicitly requiring and formatting scratch to nocrc/v4, as
the test cannot otherwise be triggered on v5 without the ikeep option.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 16 Dec 2025 18:29:56 +0000 (10:29 -0800)]
xfs/649: fix various problems
Fix a couple of problems with this new test:
First, the comment for the $attr_size_bytes check says that the maximum
size of a single xattr value is 64k. This is true, but the check
triggers the warning even when the size is exactly 64k.
Second, the test fails to format with 32k and 64k fsblock size
filesystems because the scsi_debug device size is 128M, and that's not
large enough for the minimum log size. Raise that to 320M.
Cc: fstests@vger.kernel.org # v2025.12.09 Fixes: 5760b2105985bf ("xfs: test case for handling io errors when reading extended attributes") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 16 Dec 2025 18:29:41 +0000 (10:29 -0800)]
common/rc: fix _xfs_is_realtime_file for internal rt devices
Now that we can have internal realtime devices, it's possible to have a
realtime filesystem without setting USE_EXTERNAL=yes or SCRATCH_RTDEV.
Use the existing _xfs_has_feature helper to figure out if the given path
points to a filesystem with an online realtime volume.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 16 Dec 2025 18:29:25 +0000 (10:29 -0800)]
check: put temporary files in TMPDIR, not /tmp
Nowadays, systemd will auto-remove files from /tmp after 10 days. If
you want to run a testcase for more than that duration (e.g.
SOAK_DURATION=14d) then the test will fail after the .out file is
deleted:
xfs/286 _check_xfs_filesystem: filesystem on /dev/sda4 is inconsistent (r)
(see /var/tmp/fstests/xfs/286.full for details)
sed: can't read /tmp/2098.out: No such file or directory
- output mismatch (see /var/tmp/fstests/xfs/286.out.bad)
mv: cannot stat '/tmp/2098.out': No such file or directory
diff: /var/tmp/fstests/xfs/286.out.bad: No such file or directory
This happens because systemd-tmpfiles garbage collects any file in /tmp
that becomes older than 10 days:
$ cat /usr/lib/tmpfiles.d/tmp.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details.
# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
This is now the default in Debian 13 (D12 never deleted anything) which
is why I didn't notice this until I upgraded a couple of weeks ago.
Most people aren't going to be running a single testcase for more than
10 days so I'll go with the least invasive solution that I can think of.
Allow system administrators or fstests runners to set TMPDIR to a
directory that won't get purged, and make fstests follow that. Fix up
generic/002 so that it doesn't use $tmp for paths on the test
filesystem.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Wed, 17 Dec 2025 17:00:22 +0000 (01:00 +0800)]
fstests: fix flaky device name in _cleanup_flakey
There is no device named flakey-test, which _cleanup_flakey() currently
uses. The actual device name is stored in $FLAKEY_NAME and is set to
flakey-test.$seq. Use $FLAKEY_NAME instead.
Signed-off-by: Anand Jain <asj@kernel.org> Fixes: 603030dee015ba ("fstests: per-test dmflakey instances") Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Require a real SCRATCH_RTDEV instead of faking one up using a loop
device, as otherwise the options specified in MKFS_OPTIONS might
not actually work the configuration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Require a real SCRATCH_RTDEV instead of faking one up using a loop
device, as otherwise the options specified in MKFS_OPTIONS might
not actually work the configuration.
Note that specifying a rtextsize doesn't work for zoned file systems,
so _notrun when mkfs 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>
Require a real SCRATCH_RTDEV instead of faking one up using a loop
device, as otherwise the options specified in MKFS_OPTIONS might
not actually work the configuration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
This tests expects to have at least 400M on the scratch device.
Ensure that, even if test runs with small devices will probably
break in all kinds of other funny ways.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Require a real SCRATCH_RTDEV instead of faking one up using a loop
device, as otherwise the options specified in MKFS_OPTIONS might
not actually work the configuration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
This tests forces external devices to be disabled by calling mkfs.xfs
directly and overriding SCRATCH_{LOG,RT}DEV, but the options specified in
MKFS_OPTIONS might not work for this configuration. Instead hard code
the calls to xfs_db and don't modify the scratch device configuration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
This tests creates loop-based data and rt devices for testing. Don't
override SCRATCH_{,RT}DEV and don't use the helpers based on it because
the options specified in MKFS_OPTIONS might not work for this
configuration. This also means that we will now never use a log device
for this test even if SCRATCH_LOGDEV was set, which is fine because the
log device is not relevant for what is tested.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
This tests wants to test various difference device configurations,
and does so by overriding SCRATCH_{,LOG,RT}DEV. This has two downside:
1) the actual SCRATCH_{,LOG,RT}DEV configuration is still injected by
default, thus making the test dependent on that configuration
2) the MKFS_OPTIONS might not actually be compatible with the
configuration created
Fix this by open coding the mkfs, db, admin and repair calls and always
run them on the specific configuration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Currently generic/590 runs a very different test on XFS that creates
a lot device and so on. Split that out into a new XFS-specific test,
and let generic/590 always run using the file system parameter specified
in the config even for XFS.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anand Jain <asj@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
_check_dev_fs is the new designated helper to check file systems on
arbitrary devices, use that instead of _check_generic_filesystem, which
is just an implementation detail.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anand Jain <asj@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Add a helper to run the file system checker for a given device, and stop
overloading _check_scratch_fs with the optional device argument that
creates complication around scratch RT and log devices.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anand Jain <asj@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
_check_scratch_fs takes an optional device name, but no optional
arguments. Call e2fsck directly for this extN-specific test instead.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anand Jain <asj@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
_init_flakey already overrides SCRATCH_LOGDEV and SCRATCH_RTDEV so that
the XFS-specific helpers work fine with external devices. Do the same
for SCRATCH_DEV itself, so that _scratch_mount and _scratch_unmount just
work, and so that _check_scratch_fs does not need to override the main
device.
This requires some small adjustments in how generic/741 checks that
mounting the underlying device fails, but the new version actually is
simpler than the old one, and in xfs/438 where we need to be careful
where to create the custom dm table.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anand Jain <asj@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs: add a test that zoned file systems with rump RTG can't be mounted
Garbage collection assumes all zones contain the full amount of blocks.
Mkfs already ensures this happens, but the kernel mount code did not
verify this. Instead such a file system would eventually fail scrub.
Add a test to verify the new superblock verifier check.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Su Yue [Mon, 8 Dec 2025 06:58:29 +0000 (14:58 +0800)]
generic: use _qmount_option and _qmount
This commit touches generic tests call `_scratch_mount -o usrquota`
then chmod 777, quotacheck and quotaon. They can be simpilfied
to _qmount_option and _qmount. _qmount already calls quotacheck,
quota and chmod ugo+rwx. The conversions can save a few lines.
Signed-off-by: Su Yue <glass.su@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Carlos Maiolino [Sun, 21 Dec 2025 10:24:50 +0000 (11:24 +0100)]
punch-alternating: prevent punching all extents
If by any chance the punch size is >= the interval, we end up punching
everything, zeroing out the file.
As this is not a tool to dealloc the whole file, so force the user to
pass a configuration that won't cause it to happen.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 3 Dec 2025 15:43:08 +0000 (10:43 -0500)]
generic: add tests for directory delegations
With the advent of directory delegation support coming to the kernel,
add support for testing them to the existing locktest.c program, and add
testcases for all of the different ways that they can be broken.
Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs/049: create the nested XFS file systems on the loop device
Without this I see failures on 4k sector size RT devices, as mkfs.xfs
can't pick up the logical block size on files. Note that the test
already does this for the nested ext2 image as well.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Otherwise the error injection to the data device might not work as
expected. For example in some zoned setups I see the failures in
a slightly different spot than expected without this.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Wed, 3 Dec 2025 17:38:14 +0000 (17:38 +0000)]
generic: test journaling after renaming fsynced file and fsync parent dir
Test that if we fsync a file, create a directory in the same parent
directory of the file, add a file to the new directory, rename the
initial file and then fsync the parent directory of the first file, after
a power failure the new directory exists, with its new entry and the first
file has the new name and any data we wrote to it before its fsync.
This exercises a reported btrfs bug which is fixed by a patch with the
following subject:
"btrfs: do not skip logging new dentries when logging a new name"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 27 Nov 2025 18:17:44 +0000 (18:17 +0000)]
generic: test a scenario of power failure after renames and fsyncs
Test moving a directory to another location, create a file in the old
location of the directory and with the same name, fsync the file, then
move the file elsewhere and fsync again the file. After a power failure
we expect to be able to mount the fs and have the same content as before
the power failure.
This exercises a bug fixed by the following kernel patch for btrfs:
"btrfs: don't log conflicting inode if it's a dir moved in the current transaction"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 4 Dec 2025 21:53:17 +0000 (13:53 -0800)]
fsstress: allow multiple suboptions to -f
I got bitten by fsstress's argument parsing recently because it turns
out that if you do:
# fsstress -z -f creat=2,unlink=1
It will ignore everything after the '2' and worse yet it won't tell you
that it's done so unless you happen to pass -S to make it spit out the
frequency table.
Adapt process_freq to tokenize the argument string so that it can handle
a comma-separated list of key-value arguments.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Donald Douwsma [Wed, 19 Nov 2025 04:12:10 +0000 (15:12 +1100)]
xfs: test case for handling io errors when reading extended attributes
We've seen reports from the field panicking in xfs_trans_brelse after an
IO error when reading an attribute block.
sd 0:0:23:0: [sdx] tag#271 CDB: Read(16) 88 00 00 00 00 00 9b df 5e 78 00 00 00 08 00 00
critical medium error, dev sdx, sector 2615107192 op 0x0:(READ) flags 0x1000 phys_seg 1 prio class 2
XFS (sdx1): metadata I/O error in "xfs_da_read_buf+0xe1/0x140 [xfs]" at daddr 0x9bdf5678 len 8 error 61
BUG: kernel NULL pointer dereference, address: 00000000000000e0
...
RIP: 0010:xfs_trans_brelse+0xb/0xe0 [xfs]
Signed-off-by: Donald Douwsma <ddouwsma@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Fri, 14 Nov 2025 19:48:52 +0000 (20:48 +0100)]
overlay: add tests for casefolded layers
Overalyfs did not allow mounting layers with casefold capable fs
until kernel v6.17 and did not allow casefold enabled layers
until kernel v6.18.
Since kernel v6.18, overalyfs allows this kind of setups,
as long as the layers have consistent encoding and all the directories
in the subtree have consistent casefolding.
Create test cases for the following scenarios:
- Mounting overlayfs with casefold disabled
- Mounting overlayfs with casefold enabled
- Lookup subdir in overlayfs with mismatch casefold to parent dir
- Change casefold of underlying subdir while overalyfs is mounted
- Mounting overlayfs with strict enconding, but casefold disabled
- Mounting overlayfs with strict enconding casefold enabled
- Mounting overlayfs with layers with inconsistent UTF8 version
Co-developed-by: André Almeida <andrealmeid@igalia.com> Signed-off-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>
Chao Yu [Mon, 3 Nov 2025 06:21:43 +0000 (14:21 +0800)]
f2fs: test sanity check condition w/ error injection
After commit 5c1768b67250 ("f2fs: fix to do sanity check correctly on
i_inline_xattr_size"), f2fs should handle corrupted i_inline_xattr_size
correctly, let's add this regression testcase to check that.
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>
Currently, f2fs/019 and f2fs/020 only clears MKFS_OPTIONS. This causes
the tests to fail when leftover MOUNT_OPTIONS depend on unapplied
MKFS_OPTIONS. So MOUNT_OPTIONS should also be cleared to ensure reliable
mounting.
Joanne Chang [Wed, 12 Nov 2025 13:52:21 +0000 (13:52 +0000)]
f2fs/015: clear MKFS_OPTIONS and MOUNT_OPTIONS
Currently, residual options can interfere with checking the mount
behavior of the listed MKFS_OPTIONS and MOUNT_OPTIONS. For example,
"Option#120: test_dummy_encryption" should fail with the listed
options but succeeds if “MKFS_OPTIONS=encrypt” is preset. By
explicitly clearing MKFS_OPTIONS and MOUNT_OPTIONS, the test’s
reliability can be improved.
f2fs/015.out is also updated to expect failure for cases that require
additional mkfs attributes to mount.
Darrick J. Wong [Mon, 10 Nov 2025 18:27:51 +0000 (10:27 -0800)]
generic/774: turn off lfsr
This test fails mostly-predictably across my testing fleet with:
--- /run/fstests/bin/tests/generic/774.out 2025-10-20 10:03:43.432910446 -0700
+++ /var/tmp/fstests/generic/774.out.bad 2025-11-10 01:14:58.941775866 -0800
@@ -1,2 +1,11 @@
QA output created by 774
+fio: failed initializing LFSR
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 0, length 33554432 (requested block: offset=0, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 33554432, length 33554432 (requested block: offset=33554432, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 67108864, length 33554432 (requested block: offset=67108864, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 100663296, length 33554432 (requested block: offset=100663296, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 134217728, length 33554432 (requested block: offset=134217728, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 167772160, length 33554432 (requested block: offset=167772160, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 201326592, length 33554432 (requested block: offset=201326592, length=33554432)
+verify: bad magic header 0, wanted acca at file /opt/test-file offset 234881024, length 33554432 (requested block: offset=234881024, length=33554432)
Silence is golden
I'm not sure why the linear feedback shift register algorithm is
specifically needed for this test.
Cc: fstests@vger.kernel.org # v2025.10.20 Fixes: 9117fb93b41c38 ("generic: Add atomic write test using fio verify on file mixed mappings") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 10 Nov 2025 18:27:35 +0000 (10:27 -0800)]
generic/774: reduce file size
We've gotten complaints about this test taking hours to run and
producing stall warning on test VMs with a large number of cpu cores. I
think this is due to the maximum atomic write unit being very large on
XFS where we can fall back to a software-based out of place write
implementation.
On the victim machine, the atomic write max is 4MB and there are 24
CPUs. As a result, aw_bsize to be 1MB, so the file size is
1MB * 24 * 2 * 100 == 4.8GB. I set up a test machine with fast storage
and 24 CPUs, and the atomic writes poked along at 25MB/s and the total
runtime was 300s. On spinning rust those stats will be much worse.
Let's try backing the file size off by 10x and see if that eases the
complaints.
Cc: fstests@vger.kernel.org # v2025.10.20 Fixes: 9117fb93b41c38 ("generic: Add atomic write test using fio verify on file mixed mappings") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 10 Nov 2025 18:27:20 +0000 (10:27 -0800)]
xfs/837: fix test to work with pre-metadir quota mount options
Prior to metadir, xfs users always had to supply quota mount options to
get quota functionality, even if the mount options match the ondisk
superblock's qflag state. The kernel, in turn, required a writable
filesystem if any mount options were specified. As a result, this test
fails on those old filesystems because the _scratch_mount fails.
Metadir filesystems reuse whatever's in qflags if no mount options are
supplied, so we don't need them in MOUNT_OPTS anymore.
Change the _scratch_mount to _try_scratch_mount and add configurable
golden output to handle this case.
Cc: fstests@vger.kernel.org # v2025.06.22 Fixes: e225772353e212 ("xfs: add mount test for read only rt devices") 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 [Mon, 10 Nov 2025 18:27:04 +0000 (10:27 -0800)]
generic/019: skip test when there is no journal
This test checks a filesystem's ability to recover from a noncritical
disk failure (e.g. journal replay) without becoming inconsistent. This
isn't true for any filesystem that doesn't have a journal, so we should
skip the test on those platforms.
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 [Mon, 10 Nov 2025 18:26:48 +0000 (10:26 -0800)]
generic/778: fix background loop control with sentinel files
This test fails on my slowish QA VM with 32k-fsblock xfs:
--- /run/fstests/bin/tests/generic/778.out 2025-10-20 10:03:43.432910446 -0700
+++ /var/tmp/fstests/generic/778.out.bad 2025-11-04 12:01:31.137813652 -0800
@@ -1,2 +1,137 @@
QA output created by 778
-Silence is golden
+umount: /opt: target is busy.
+mount: /opt: /dev/sda4 already mounted on /opt.
+ dmesg(1) may have more information after failed mount system call.
+cycle mount failed
+(see /var/tmp/fstests/generic/778.full for details)
Injecting a 'ps auxfww' into the _scratch_cycle_mount helper reveals
that this process is still sitting on /opt:
Yes, that's the xfs_io process started by atomic_write_loop.
Inexplicably, the awloop killing code terminates the subshell running
the for loop in atomic_write_loop but only waits for the subshell itself
to exit. It doesn't wait for any of that subshell's children, and
that's why the unmount fails.
A bare "wait" (without the $awloop_pid parameter) also doesn't wait for
the xfs_io because the parent shell sees the subshell exit and treats
that as job completion. We can't use killall here because the system
could be running check-parallel, nor can we use pkill here because the
pid namespace containment code was removed.
The simplest stupid answer is to use sentinel files to control the loop.
Cc: fstests@vger.kernel.org # v2025.10.20 Fixes: ca954527ff9d97 ("generic: Add sudden shutdown tests for multi block atomic writes") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 10 Nov 2025 18:26:32 +0000 (10:26 -0800)]
generic/778: fix severe performance problems
This test takes 4800s to run, which is horrible. AFAICT it starts out
by timing how much can be written atomically to a new file in 0.2
seconds, then scales up the file size by 3x. On not very fast storage,
this can result in file_size being set to ~250MB on a 4k fsblock
filesystem. That's about 64,000 blocks.
The next thing this test does is try to create a file of that size
(250MB) of alternating written and unwritten blocks. For some reason,
it sets up this file by invoking xfs_io 64,000 times to write small
amounts of data, which takes 3+ minutes on the author's system because
exec overhead is pretty high when you do that.
As a result, one loop through the test takes almost 4 minutes. The test
loops 20 times, so it runs for 80 minutes(!!) which is a really long
time.
So the first thing we do is observe that the giant slow loop is being
run as a single thread on an empty filesystem. Most of the time the
allocator generates a mostly physically contiguous file. We could
fallocate the whole file instead of fallocating one block every other
time through the loop. This halves the setup time.
Next, we can also stuff the remaining pwrite commands into a bash array
and only invoke xfs_io once every 128x through the loop. This amortizes
the xfs_io startup time, which reduces the test loop runtime to about 20
seconds.
Finally, replace the 20x loop with a _soak_loop_running 5x loop because
5 seems like enough. Anyone who wants more can set TIME_FACTOR or
SOAK_DURATION to get more intensive testing. On my system this cuts the
runtime to 75 seconds.
Cc: fstests@vger.kernel.org # v2025.10.20 Fixes: ca954527ff9d97 ("generic: Add sudden shutdown tests for multi block atomic writes") 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 [Mon, 10 Nov 2025 18:26:17 +0000 (10:26 -0800)]
common: leave any breadcrumbs when _link_out_file_named can't find the output file
_link_out_file_named is an obnoxiously complicated helper involving a
perl script embedded inside a bash subshell that does ... a lookup of
some sort involving comparing the comma-separated list in its second
argument against a comma-separated list in a config file that then maps
to an output file suffix. I don't know what it really does. The .cfg
file format is undocumented except for the perl script.
This is really irritating every time I have to touch any of these tests
with flexible golden outputs, and I frequently screw up the mapping.
The helper is not very helpful when you do this, because it doesn't even
try to tell you *which* suffix it found, let alone how it got there.
Fix this up so that the .full file gets some diagnostics, even if the
stdout text is "no qualified output".
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Theodore Ts'o [Fri, 14 Nov 2025 01:02:38 +0000 (20:02 -0500)]
generic/773: fix expected output "QA output created by 1226"
The test generic/773 was apparently submitted as generic/1226, but
when it was renamed to pack the test namespace, apparently the test
output wasn't adjusted to reflect the new test name, leading to the
test failing on sytems that have devices that support atomic writes.
Fixes: 1499d4ff2365 ("generic: Add atomic write test using fio crc ...") Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / xfstests-dev.git / log