generic: test premature ENOSPC in zoned garbage collection
This test stresses garbage collection in zoned file systems by
constantly overwriting the same file. It is inspired by a reproducer
for a btrfs bugfix.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs: add a test for number of open zones on conventional devices
Test that mounts of zoned file systems on conventional devices don't
create more open zones than allowed when the last blocks in one or more
zones have been invalidated.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jan Prusakowski [Fri, 10 Apr 2026 13:18:20 +0000 (13:18 +0000)]
generic/050: handle f2fs as nojournal filesystem
F2FS uses a checkpoint mechanism for metadata consistency rather than a
traditional journal. Roll-forward recovery is only needed if there are
fsync'd files since the last checkpoint.
In this test case, files are created without fsync, so there is no
roll-forward data to replay during mount.
Therefore, F2FS does not need to write to the device to recover, and
successfully mounts on the read-only block device. Thus, it should be
treated as nojournal in this case.
Signed-off-by: Jan Prusakowski <jprusakowski@google.com> Reviewed-by: Zorro Lang <zlang@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 9 Apr 2026 15:22:27 +0000 (16:22 +0100)]
generic: test fsync against a removed directory
Test that if we fsync a directory that became empty after removing it
and we have a power failure, we are able to mount the filesystem and the
directory does not exists anymore.
This exercises a bug found in btrfs which is fixed by the following patch:
btrfs: fix missing last_unlink_trans update when removing a directory
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Zorro Lang <zlang@kernel.org>
treewide: Use _sysfs_queue_path helper in all queue access locations
The sysfs queue dir for partitions is present in their parent device's
sysfs dir. This requires extra checks when trying to reading queue data
from sysfs. Currently, fstests open codes this handling or straight up
ignores it in some places.
Avoid this by converting all remaining direct sysfs queue accesses to
use the _sysfs_queue_path helper function. This ensures proper handling
of partitions across the entire codebase and provides a consistent
interface for accessing queue attributes.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/775: Fix an infinite loop due to variable name clash
We use i as the iteration variable in the main test loop as well as some
internal loops. Due to this clash, $i variable of main test loops was
getting modified by the following loop in prep_mixed_mapping().
for ((i=0; i<num_blocks; i++)); do
If num_blocks is less than 10 (example ext4 with blocksize 4k and
cluster size 8k) i would always be set as 3 and the main loop would
never exit. Use local variable to fix this and while we are at it,
rename it for clarity.
Reported-by: Disha Goel <disgoel@linux.ibm.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/765: Fix sysfs queue path for nvme partitions
This tests checks atomic write limits reported by statx() are same as
the ones reported by sysfs, however nvme partitions don't have the
/sys/block/nvme0n1p1 style entry and also use the namespace's queue
limits for atomic writes. This causes the test to fail because it
expects /sys/block/nvme0n*p* to be present.
Hence, use the new _sysfs_queue_path() helper to get the correct
atomic write limits
Also, fix a small typo (s/awu_min/awu_max) when printing awu limits to
seqres.full
Reported-by: Disha Goel <disgoel@linux.ibm.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
common/rc: Add _sysfs_queue_path helper with partition support
Add a generic helper function to get the sysfs queue path for block
devices, properly handling partitions. Partitions don't have their own
queue directory in sysfs - they inherit from their parent device.
This helper checks if a device is a partition and returns the parent
device's queue path accordingly, making it easier to access queue
attributes for both whole disks and partitions.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
The tests use block device's limits instead of limits advertised
by filesystem. This can cause failures because block device might
advertise a higher maximum than the FS. Fix the tests to use
filesystem's limits instead.
2. Fix the test loop range
Fix the test loop start and end so that our calculations for
blocksize, clustersize and iosize are correct.
Reported-by: Disha Goel <disgoel@linux.ibm.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Disha Goel [Mon, 23 Mar 2026 12:40:05 +0000 (18:10 +0530)]
generic/730: skip test if DAX mount option is enabled
The generic/730 test utilizes the scsi_debug driver to create a
synthetic SCSI block device. Since scsi_debug does not support
DAX capabilities, attempting to mount it with "-o dax" results
in failures (specifically on ext4).
Since this test is not DAX-related, exclude it when DAX is
specified in MOUNT_OPTIONS to avoid compatibility issues with
scsi_debug.
Signed-off-by: Disha Goel <disgoel@linux.ibm.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Long Li [Wed, 1 Apr 2026 06:06:32 +0000 (14:06 +0800)]
xfs/018: test log attr replay with zero-length attr value
Kernel commit d72f2084e309 ("xfs: fix ri_total validation in
xlog_recover_attri_commit_pass2") fixed a bug where setting a
zero-length attribute value would cause incorrect ri_total
validation during log recovery.
Add test cases to xfs/018 to cover this scenario across attr
fork formats: extent and remote.
Using echo -n "" | attr -s is unreliable for empty values since
attr may treat stdin EOF as no value provided. Instead, handle
zero-length values explicitly in test_attr_replay() by using
attr -s -V "" when the value is empty.
Signed-off-by: Long Li <leo.lilong@huawei.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 31 Mar 2026 14:15:10 +0000 (15:15 +0100)]
fstests: add kernel commit IDs for patches already merged upstream
Several tests mention patches that are already in Linus' git tree, so add
their commit IDs. For generic/762, also use "fixed_by_fs_commit xfs"
instead of "_fixed_by_git_commit kernel" since it's a XFS specific commit
and it does not make sense for the test to report that commit in case it
fails when running against a filesystem other than XFS.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hans Holmberg [Fri, 27 Mar 2026 12:34:29 +0000 (13:34 +0100)]
xfs: test that zone_gc_low_space writes start gc for rw fses
Test that writes to the sysfs attribute zone_gc_low_space triggers
garbage collection for rw (but not ro) file systems.
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hans Holmberg [Fri, 27 Mar 2026 12:34:28 +0000 (13:34 +0100)]
xfs/647: turn rt dev block device lookup into a common helper
Turn the logic figuring out on which block device the rt data is stored on
into a common helper.
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Leo Martins [Tue, 24 Mar 2026 19:09:52 +0000 (12:09 -0700)]
btrfs: fix stale errno check in btrfs_encoded_read/write helpers
The atoll() error check `if (offset == 0 && errno != 0)` can falsely
trigger because errno is not cleared before the call. Library
initialization code (e.g. libcap calling prctl(PR_CAPBSET_READ) which
fails with EINVAL) can leave errno set to a non-zero value. When the
caller passes offset=0 (a valid value), atoll() returns 0 without
modifying errno, and the stale errno causes the helper to print usage
and exit.
This caused btrfs/333 to fail consistently on systems where libcap is
linked, since every call with offset 0 would bail out.
Fix by clearing errno before the atoll() calls in both
btrfs_encoded_read and btrfs_encoded_write helpers.
Signed-off-by: Leo Martins <loemra.dev@gmail.com> Reviewed-by: Mark Harmstone <mark@harmstone.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Leo Martins [Tue, 24 Mar 2026 20:40:00 +0000 (13:40 -0700)]
generic/301: skip extent count check on btrfs
The 2/3 fragmentation threshold was designed for XFS's cowextsize
mechanism and is not applicable to btrfs. After commit 0dc118b3c327
("btrfs: be less aggressive with metadata overcommit when we can do
full flushing"), btrfs commits transactions more frequently during
writeback, reducing the extent allocator's opportunity to coalesce
adjacent CoW extents. This causes the extent count to sometimes cross
the threshold, making the test flaky on btrfs.
Skip only the extent count assertion for btrfs while keeping the CoW
write + remount + md5sum data integrity checks, which remain useful.
Signed-off-by: Leo Martins <loemra.dev@gmail.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yangyang Zang [Thu, 19 Mar 2026 03:35:19 +0000 (11:35 +0800)]
f2fs: add testcase to check resize corrupting root inode
This is a regression test to check whether the f2fs root inode
is corrupted after the resize operation.
During the resize operation, SSA data blocks are migrated and
zeroed. This process may incorrectly zero out the main area
blocks, leading to root inode corruption.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Chao Yu <chao@kernel.org> Signed-off-by: Yangyang Zang <zangyangyang1@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 16 Mar 2026 23:29:35 +0000 (16:29 -0700)]
xfs/805: adjust for new autofsck fsproperty defaults
Now that mkfs will set autofsck=repair for filesystems that have both
reverse space mappings and file parent pointers enabled, let's stop
testing the "no autofsck option at all" scenario to avoid problems with
older mkfs.
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, 16 Mar 2026 23:29:19 +0000 (16:29 -0700)]
xfs/6{59-61}: force xfs_healer to run
Set the autofsck property so that xfs_healer actually runs on
filesystems with old feature sets. Since these tests are looking for
error reports that don't require backref metadata (media errors, file IO
errors, shutdowns) we needn't _notrun them.
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 [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>
projects / xfstests-dev.git / log