Darrick J. Wong [Thu, 12 Mar 2026 14:21:30 +0000 (07:21 -0700)]
xfs: test xfs_healer can follow private mntns mount moves
Make sure that when xfs_healer needs to reopen a filesystem to repair
it, it can still find the filesystem even if it has been mount --move'd.
This requires a bunch of private namespace magic.
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, 10 Mar 2026 03:53:15 +0000 (20:53 -0700)]
xfs: test xfs_healer wont repair the wrong filesystem
Make sure that when xfs_healer needs to reopen a filesystem to repair it, it
won't latch on to another xfs filesystem that has been mounted atop the same
mountpoint.
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, 10 Mar 2026 03:51:10 +0000 (20:51 -0700)]
xfs: set up common code for testing xfs_healer
Add a bunch of common code so that we can test the xfs_healer daemon.
Most of the changes here are to make it easier to manage the systemd
service units for xfs_healer and xfs_scrub.
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, 10 Mar 2026 03:50:08 +0000 (20:50 -0700)]
generic: test fsnotify filesystem error reporting
Use dmerror to inject a media error for a file's storage, then run
some IO and make sure that fanotify reports the IO errors.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 11 Mar 2026 04:14:43 +0000 (21:14 -0700)]
xfs/62[3-8]: require XFS_SCRUB_PROG
QA reports that xfs/62[3-8] fail because they didn't install
xfsprogs-xfs_scrub package and this test requires xfs_scrub(8).
Add the missing _require call, and update the README so that anyone
running fstests on RHEL/Fedora actually get all the necessary
components to do a full test of XFS.
Cc: fstests@vger.kernel.org # v2024.06.27 Fixes: 4de8fd7860a2bb ("scrub: test correction of directory tree corruptions") Signed-off-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 [Thu, 26 Feb 2026 14:34:37 +0000 (14:34 +0000)]
btrfs: test create a bunch of files with name hash collision
Test that if we create a high number of files with a name that results in
a hash collision, the filesystem is not turned to RO due to a transaction
abort. This could be exploited by malicious users to disrupt a system.
This exercies a bug fixed by the following kernel patch:
"btrfs: fix transaction abort on file creation due to name hash collision"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 26 Feb 2026 14:34:24 +0000 (14:34 +0000)]
btrfs: test creating a large number of snapshots of a received subvolume
Test that we can create a large number of snapshots of a received
subvolume without triggering a transaction abort due to leaf item
overflow. Also check that we are able to delete the snapshots and use
the last one for an incremental send/receive despite an item overflow
when updating the uuid tree to insert a BTRFS_UUID_KEY_RECEIVED_SUBVOL
item.
This exercises a bug fixed by the following kernel patch:
"btrfs: fix transaction abort when snapshotting received subvolumes"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 27 Feb 2026 00:12:05 +0000 (00:12 +0000)]
btrfs: test setting the same received UUID to a lot of subvolumes
Test that using the received subvol ioctl to set a received UUID on a root
does not trigger a transaction abort (and turn the filesystem to RO mode)
if a user abuses by assigning the same received UUID to a large number of
subvolumes.
This exercises a bug fixed by the following kernel patch:
"btrfs: fix transaction abort on set received ioctl due to item overflow"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <asj@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
fstests: use _fixed_by_fs_commit where appropriate
Use the newly introduced _fixed_by_fs_commit function where appropriate.
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Add a new helper `_fixed_by_fs_commit` eliminating the
if [ $FSTYP = fs ] && _fixed_by_kernel_commit XXXX YYYY
pattern.
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 3 Mar 2026 18:07:33 +0000 (18:07 +0000)]
generic: test a directory fsync scenaro after replacing a subdir with a file
Test a scenario where we remove a directory previously persisted, create
a file with the same name and parent directory, create two directories in
the same parent directory, create a hard link for the new file in one of
the new directories, fsync the directory with the hard link and fsync the
parent directory. After a power failure we expect both directories to be
persisted as well as the new file and its hard link.
This exercises a bug on btrfs fixed by the following kernel patch:
"btrfs: log new dentries when logging parent dir of a conflicting inode"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jan Kara [Fri, 20 Feb 2026 20:33:08 +0000 (21:33 +0100)]
tests: Fix failure in nojournal mode
Several tests use fs shutdown. Without journalling the filesystem isn't
guaranteed to be consistent after shutdown. So for tests that don't make
sure data makes it to the disk using fsync/sync we cannot really test
much. Skip such tests without journalling.
Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 17 Feb 2026 18:33:30 +0000 (18:33 +0000)]
generic: test fsync of a file truncated to a length of zero
Test that if we truncate a file to 0, fsync it, add a hard link to the
file and then fsync the parent directory, after a power failure the file
has a size of 0 (and the hardlink exists too).
This exercises a bug fixed by the following kernel patch for btrfs:
"btrfs: fix zero size inode with non-zero size after log replay"
Signed-off-by: Filipe Manana <fdmanana@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>
Qu Wenruo [Mon, 16 Feb 2026 21:29:24 +0000 (07:59 +1030)]
fstests: btrfs: add a test case for failed compressed inline attempt
[BUG]
There is a long existing behavior that if a compressed inline attempt
failed, the whole inode is marked incompressible.
Furthermore, the default threshold for compressed inline implies a
pretty high compression ratio (2K max inline vs 4K block size, thus 50%
compression ratio).
This makes btrfs to mark inodes incompressible prematurely.
[TEST]
The new test case is based on the previous btrfs/343 one, which will do:
- Create and mount the fs with compress,max_inline=4
4 bytes will be too small for any header, thus all compressed inline
writes should fail.
- Do the following operations:
* Buffered write [0, blocksize / 2)
Which can be inlined if using the default max_inline mount option
and 4K fs block.
But the new max_inline=4 will reject such compressed inline attempt.
And such one block write should not trigger compression thus no
compression ratio based check.
* Sync
For unpatched kernels, this will set the inode with NOCOMPRESS flag
and reject all future compression on that inode.
* Buffered write [1M, 2M)
For unpatched kernels, the range will not be compressed due to the
NOCOMPRESS flag.
- Unmount the fs
- Maker sure that:
* The inode has no NOCOMPRESS flag
* File extent at file offset 1M is being compressed
Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Mon, 9 Feb 2026 09:57:35 +0000 (20:27 +1030)]
fstests: btrfs: add a regression test for incorrect inode incompressible flag
[BUG]
Since kernel commit 59615e2c1f63 ("btrfs: reject single block sized
compression early"), a single block write at file offset 0, which can
not be inlined due the inode size, will mark the inode incompressible.
[REGRESSION TEST]
The new regression test will do:
- Create and mount the fs with compression,max_inline=2k
- Do the following operations:
* Truncate the inode to 2 * blocksize
This will rule out any future inlined writes.
* Buffered write [0, 2K)
Which will not be inlined.
* Sync
For affected kernels, this will set the inode with NOCOMPRESS
and reject all future compression on that inode.
* Buffered write [1M, 2M)
For affected kernels, the range will not be compressed due
to the NOCOMPRESS flag.
- Unmount the fs
- Make sure that:
* The inode has no NOCOMPRESS flag
* File extent at file offset 1M is being compressed
Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/735 attempts to create a file with nearly 2^32 blocks. However,
some filesystems have a maximum file block limit below this threshold.
For instance, F2FS is limited to approximately 2^30 blocks due to the
capacity of the inode. So add _require_blocks_in_file helper to skip the
test in such cases.
The helper uses a hardcoded constant instead of a programmatic method,
so that bugs which affect the maximum file size are not masked.
Signed-off-by: Joanne Chang <joannechien@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 2 Feb 2026 19:11:44 +0000 (11:11 -0800)]
generic/749: don't write a ton of _mread output to seqres.full
Something went wrong with this test when testing with fuse4fs, but I
couldn't tell what because this test writes so much data to seqres.full
that it completely filled the log partition. Most of that output was
from checks that actually succeeded, so let's reduce the amount of
logging from _mread (which passes -v) by writing to a tempfile and only
dumping the output to the .full file if something breaks.
Cc: fstests@vger.kernel.org # v2024.06.27 Fixes: e4a6b119e52295 ("fstests: add mmap page boundary tests") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 2 Feb 2026 19:11:28 +0000 (11:11 -0800)]
xfs/620: force xattr leaf format for this test
Now that the kernel's parent pointer update code skips the attr intent
mechanism when the attr fork is in local/shortform format, we need to
bloat the attr fork to force the slow path for error injection testing.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Fri, 6 Feb 2026 21:54:00 +0000 (13:54 -0800)]
xfs/018: remove inline xattr recovery tests
In Linux 7.0 we've changed the extended attribute update code to try to
take a shortcut for performance reasons. Before walking through the
attr intent state machine (slow), the update will check to see if the
attr structure is in short format and will stay in that format after the
change. If so, then the incore inode can be updated and logged, and
the update is complete (fast) in a single transaction.
(Obviously, for complex attr structures or large changes we still walk
through the intent machinery.)
However, xfs/018 tests the behavior of the "larp" error injector, which
only triggers from inside the attr intent state machine. Therefore, the
short format tests don't actually trip the injector. It makes no sense
to add a new larp injection callsite for the shortcut because either the
single transaction gets written to disk or it doesn't.
The golden output no longer matches because the attr update doesn't
return EIO and shut down the filesystem due to the larp injection.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
This test currently creates a block device node for /dev/ram0,
which isn't guaranteed to exist, and can thus cause the test to
fail with:
mkfs.xfs: cannot open $TEST_DIR/proto/blockdev: No such device or address
Instead, create a node for the backing device for $TEST_DIR, which must
exist.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Luca Di Maio <luca.dimaio1@gmail.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic: test that truncate(2) on fsverity is blocked
truncate(2) doesn't go through open and needs special code to block
it on fsverity files. btrfs was missing this check.
Note that truncate(2) in current core utils uses openat and ftruncate,
so add our own little test program for it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 27 Jan 2026 15:01:52 +0000 (15:01 +0000)]
generic: add missing kernel commit IDs to tests 784 and 785
The respective kernel patches are already in Linus' tree (landed in
v6.19-rc2), so update the tests to include the commit IDs.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Luca Di Maio [Thu, 8 Jan 2026 14:22:22 +0000 (15:22 +0100)]
xfs: test reproducible builds
With the addition of the `-p` populate option, SOURCE_DATE_EPOCH and
DETERMINISTIC_SEED support, it is possible to create fully reproducible
pre-populated filesystems. We should test them here.
[zlang: use _run_fsstress]
Signed-off-by: Luca Di Maio <luca.dimaio1@gmail.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>
Darrick J. Wong [Wed, 21 Jan 2026 01:26:21 +0000 (17:26 -0800)]
misc: allow zero duration for fsstress and fsx
Occasionally the common/fuzzy fuzz test helpers manage to time
something just right such that fsx or fsstress get invoked with a zero
second duration. It's harmless to exit immediately without doing
anything, so allow this corner case.
[zlang: No action is taken if duration is 0]
Cc: fstests@vger.kernel.org # v2023.05.01 Fixes: 3e85dd4fe4236d ("misc: add duration for long soak tests") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 21 Jan 2026 01:27:00 +0000 (17:27 -0800)]
xfs/614: fix test for parent pointers
Almost a decade ago, the initial rmap/reflink patches were merged with
hugely overestimated log space reservations. Although we adjusted the
actual runtime reservations a few years ago, we left the minimum log
size calculations in place to avoid compatibility problems between newer
mkfs and older kernels.
With the introduction of parent pointers, we can finally use the more
accurate reservations for minlog computations and mkfs can format
smaller logs as a result. This causes the output of this test to
change, though it wasn't needed until parent pointers were enabled by
default.
Signed-off-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>
caokewu [Mon, 19 Jan 2026 05:54:11 +0000 (13:54 +0800)]
ext4/307: allocate donor file size dynamically
Currently, the donor file size is hardcoded to 250M. fsstress can generate
more data than this limit, which causes the `e4compact` helper to crash.
Specifically, `e4compact.c:do_defrag_range()` contains the following
assertion:
assert(donor->length >= len);
If the donor file is not large enough to accommodate the data being compacted,
this assertion fails (or validation logic rejects it), causing the test to
fail unexpectedly with an abort or error.
Additionally, the previous 'usage' calculation used `du -sch`, which outputs
human-readable sizes (e.g., "1.5M"). xfs_io's falloc command does not
support decimal values in length arguments, leading to syntax errors during
file allocation.
Fix this by:
1. Using `du -sm` to calcuate the required size in integer MB (rounding up),
avoiding decimal issues.
2. Allocating the donor file using this calculated `usage` size instead of
the fixed 250M limit, ensuring it is always large enough for the operation.
Signed-off-by: caokewu <caokewu1@uniontech.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/371: Fix the test to be compatible block sizes upto 64k
When this test was ran with btrfs with 64k sector/block size, it
failed with
QA output created by 371
Silence is golden
+fallocate: No space left on device
+pwrite: No space left on device
+fallocate: No space left on device
+pwrite: No space left on device
+pwrite: No space left on device
...
This is what is going on:
Let us see the following set of operations:
--- With 4k sector size ---
$ mkfs.btrfs -f -b 256m -s 4k -n 4k /dev/loop0
$ mount /dev/loop0 /mnt1/scratch/
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 1.5M 175M 1% /mnt1/scratch
$ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t1
wrote 83886080/83886080 bytes at offset 0
80 MiB, 20480 ops; 0.4378 sec (182.693 MiB/sec and 46769.3095 ops/sec)
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 1.5M 175M 1% /mnt1/scratch
$ sync
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 82M 95M 47% /mnt1/scratch
$ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t2
wrote 83886080/83886080 bytes at offset 0
80 MiB, 20480 ops; 0:00:01.25 (63.881 MiB/sec and 16353.4648 ops/sec)
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 137M 40M 78% /mnt1/scratch
$ sync
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 162M 15M 92% /mnt1/scratch
Now let us repeat with 64k sector size
--- With 64k sector size ---
$ mkfs.btrfs -f -b 256m -s 64k -n 64k /dev/loop0
$ mount /dev/loop0 /mnt1/scratch/
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 24M 175M 12% /mnt1/scratch
$ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t1
wrote 83886080/83886080 bytes at offset 0
80 MiB, 20480 ops; 0.8460 sec (94.553 MiB/sec and 24205.4914 ops/sec)
$
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 24M 175M 12% /mnt1/scratch
$ sync
$ df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 256M 104M 95M 53% /mnt1/scratch
$ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t2
pwrite: No space left on device
Now, we can see that with 64k node size, 256M is not sufficient
to hold 2 files worth 80M. For 64k, we can also see that the initial
space usage on a fresh filesystem is 24M and for 4k its 1.5M. So
because of higher node size, more metadata space is getting used.
This test requires the size of the filesystem to be at least capable
to hold 2 80M files.
Fix this by increasing the fs size from 256M to 330M.
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>
Qu Wenruo [Thu, 25 Dec 2025 22:15:53 +0000 (08:45 +1030)]
fstests: btrfs: add a new test case that is future-proof
Btrfs' v1 space cache is marked deprecated since commit 1e7bec1f7d65
("btrfs: emit a warning about space cache v1 being deprecated"), and
soon the v1 space cache mount option will be fully dropped.
Furthermore existing features like block-group-tree, zoned, and bs != ps
support are all rejecting v1 space cache or forcing the switch to v2
space cache.
The existing btrfs/131 is not going to handle the future well, and that
test case is mostly for LTS kernel testing now.
Add a new test case that is completely v1 cache free, so that it will
support the future where v1 cache is completely dropped, meanwhile still
keep the coverage for v2 cache and nospace_cache mount options.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Thu, 25 Dec 2025 22:15:52 +0000 (08:45 +1030)]
fstests: btrfs/131: add explicit v1 space cache requirement
The test case is utilizing v1 space cache, meanwhile v1 space cache
is already marked deprecated for a while since kernel commit 1e7bec1f7d65 ("btrfs: emit a warning about space cache v1 being
deprecated").
Furthermore quite some features are not compatible with v1 cache,
including the soon-to-be-default block-group-tree, and hardware
dependent zoned features.
Currently we reject those features for btrfs/131, but what we really
want is to only run the test case for supported features/kernels.
The current way to reject will not handle future kernels that completely
rejects v1 space cache.
Add a new helper, _require_btrfs_v1_cache() to do the check, which
checks the following criteria:
- "space_cache=v1" mount option is supported
And to handle default v2 cache behavior, also add "clear_cache".
If the kernel has completely dropped v1 cache support, such mount
should fail.
- Check if FREE_SPACE_TREE feature exists after above mount
For bs != ps cases, v2 cache is enforced to replace v1 cache, thus
we need to double check to make sure above mount didn't result v2
cache.
- Check if cache generation is correct
If v1 cache is working, the cache_generation should be some valid
value other than 0 nor (u64)-1.
And replace the existing checks on zoned and block-group-tree with the
new one.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfstests: hfs/hfsplus don't support metadata journaling
HFS file system doesn't support metadata journaling.
This patch marks HFS file system as not supporting
metadata journaling in _has_metadata_journaling()
of common/rc.
Technically speaking, HFS+ is journaling file system.
However, current Linux kernel implementation doesn't
support even journal replay. This patch marks HFS+ file
system as not supporting metadata journaling in
_has_metadata_journaling() of common/rc. If journaling
support functionality in HFS+ will be implemented,
then HFS+ could be deleted from _has_metadata_journaling()
in the future.
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
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>
projects / xfstests-dev.git / log