Christoph Hellwig [Thu, 24 Oct 2024 11:26:25 +0000 (13:26 +0200)]
xfs: handle zoned file systems in _scratch_xfs_force_no_metadir
zoned file systems required the metadir feature. If the tests are run
on a conventional block device as the RT device, we can simply remove
the zoned flag an run the test, but if the RT device sits on a zoned
block device there is no way to run a test that wants a non-metadir
file system.
Christoph Hellwig [Sun, 18 Aug 2024 04:52:39 +0000 (06:52 +0200)]
xfs/177: force a small file system size
This test make assumptions about the number of metadata inodes. When
using small realtime group size (e.g. the customary 256MB for SMR
hard drives) this assumption gets violated even with modest file system
size. Force a small file system size to side-step this issue.
Christoph Hellwig [Mon, 26 Aug 2024 07:30:35 +0000 (09:30 +0200)]
xfs: add _require_non_zoned_device calls
Add _require_non_zoned_device calls to various XFS-specific tests.
Mostly this is because they force v4 file systems or other features
that can't work on zoned devices.
Darrick J. Wong [Tue, 6 Feb 2024 00:06:50 +0000 (16:06 -0800)]
common/xfs: fix _xfs_get_file_block_size when rtinherit is set and no rt section
It's possible for the sysadmin to set rtinherit on the directory tree
even if there isn't a realtime section attached to the filesystem. When
this is the case, the realtime flag is /not/ passed to new files, and
file data is written to the data device. The file allocation unit for
the file is the fs blocksize, and it is not correct to use the rt
extent.
fstests can be fooled into doing the incorrect thing if test runner puts
'-d rtinherit=1 -r extsize=28k' into MKFS_OPTIONS without configuring a
realtime device. This causes many tests to do the wrong thing because
they think they must operate on units of 28k (and not 4k). Fix this.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:50 +0000 (16:06 -0800)]
generic/331,xfs/240: support files that skip delayed allocation
The goal of this test is to ensure that log recovery finishes a copy on
write operation in the event of temporary media errors. It's important
that the test observe some sort of IO error once we switch the scratch
device to fail all IOs, but regrettably the test encoded the specific
behavior of XFS and btrfs when the test was written -- the aio write
to the page cache doesn't have to touch the disk and succeeds, and the
fdatasync flushes things to disk and hits the IO error.
However, this is not how things work on the XFS realtime device. There
is no delalloc on realtime, so the aio write allocates an unwritten
extent to stage the write. The allocation fails due to EIO, so it's the
write call that fails. Therefore, all we need to do is to detect an IO
error at any point between the write and the fdatasync call to be
satisfied that the test does what we want to do.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:47 +0000 (16:06 -0800)]
fuzzy: create missing fuzz tests for rt rmap btrees
Back when I first created the fuzz tests for the realtime rmap btree, I
forgot a couple of things. Add tests to fuzz rtrmap btree leaf records,
and node keys.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:47 +0000 (16:06 -0800)]
populate: adjust rtrmap calculations for rtgroups
Now that we've sharded the realtime volume and created per-group rmap
btrees, we need to adjust downward the size of rtrmapbt records since
the block counts are now 32-bit instead of 64-bit.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs: skip tests if formatting small filesystem fails
There are a few tests that try to exercise XFS functionality with an
unusually small (< 500MB) filesystem. Formatting can fail if the test
configuration also specifies a very large realtime device because mkfs
hits ENOSPC when allocating the realtime metadata. The test proceeds
anyway (which causes an immediate mount failure) so we might as well
skip these.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs/3{43,32}: adapt tests for rt extent size greater than 1
Both of these tests for the realtime volume can fail when the rt extent
size is larger than a single block.
332 is a read-write functionality test that encodes md5sum in the
output, so we need to skip it if $blksz isn't congruent with the extent
size, because the fcollapse call will fail.
343 is a test of the rmap btree, so the fix here is simpler -- make
$blksz the file allocation unit, and get rid of the md5sum in the
golden output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs/341: update test for rtgroup-based rmap
Now that we're sharding the realtime volume into multiple allocation
groups, update this test to reflect the new reality. The realtime rmap
btree record and key sizes have shrunk, and we can't guarantee that a
quick file write actually hits the same rt group as the one we fuzzed,
so eliminate the file write test since we're really only curious if
xfs_repair will fix the problem.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs: fix various problems with fsmap detecting the data device
Various tests of realtime rmap functionality assumed that the data
device could be picked out from the GETFSMAP output by looking for
static fs metadata. This is no longer true, since rtgroups have a
static superblock header at the start, so update these tests.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:45 +0000 (16:06 -0800)]
xfs/122: update for rtgroups-based realtime rmap btrees
Now that we've redesigned realtime rmap to require that the rt section
be sharded into allocation groups of no more than 2^31 blocks, we've
reduced the size of the ondisk structures and therefore need to update
this test.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:45 +0000 (16:06 -0800)]
fuzz: for fuzzing the rtrmapbt, find the path to the rt rmap btree file
The fs population code creates a realtime rmap btree in /some/ realtime
group with at least two levels. This rmapbt file isn't necessarily the
one for group 0, so we need to find it programmatically.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:44 +0000 (16:06 -0800)]
xfs: fix tests that try to access the realtime rmap inode
The realtime rmap tests were added to fstests a long time ago. Since
they were added, we decided to create a metadata file directory
structure instead of adding more fields to the superblock. Therefore,
fix all the tests that try to access these paths.
While we're at it, fix xfs/409 to run the *online* scrub program like
it's supposed to. xfs/408 is the fuzzer for xfs_repair testing.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:52 +0000 (16:06 -0800)]
common: enable testing of realtime quota when supported
If the kernel advertises realtime quota support, test it.
However, this has a plot twist -- because rt quota only works if the xfs
is formatted with rtgroups, we have to mount a filesystem to see if
rtquota is actually supported. Since it's time consuming to format and
mount the scratch filesystem, we'll assume that the test and scratch
fses have the same support.
This will cause problems if one sets SCRATCH_RTDEV but not TEST_RTDEV.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:43 +0000 (16:06 -0800)]
common/xfs: capture realtime devices during metadump/mdrestore
If xfs_metadump supports the -r switch to capture the contents of
realtime devices and there is a realtime device, add the option to the
command line to enable preservation.
Similarly, if the dump file could restore to an external scratch rtdev,
pass the -r option to mdrestore so that we can restore rtdev contents.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:42 +0000 (16:06 -0800)]
xfs/449: update test to know about xfs_db -R
The realtime groups feature added a -R flag to xfs_db so that users can
pass in the realtime device. Since we've now modified the
_scratch_xfs_db to use this facility, we can update the test to do exact
comparisons of the xfs_db info command against the mkfs output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:42 +0000 (16:06 -0800)]
xfs/185: update for rtgroups
This old test is a bit too fixated on exact rt allocator behavior. With
rtgroups enabled, we can end up with one large contiguous region that's
split into multiple bmbt mappings to avoid crossing rtgroup boundaries.
The realtime superblock throws another twist into the mix because the
first rtx will always be in use, which can shift the start of the
physical space mappings by up to 1 rtx.
Also fix a bug where we'd try to fallocate the total number of rtx,
whereas we should be asking for the number of free rtx to avoid ENOSPC
errors.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:41 +0000 (16:06 -0800)]
punch-alternating: detect xfs realtime files with large allocation units
For files on the XFS realtime volume, it's possible that the file
allocation unit (aka the minimum size we have to punch to deallocate
file blocks) could be greater than a single fs block. This utility
assumed that it's always possible to punch a single fs block, but for
these types of files, all that does is zeroes the page cache. While
that's what most *user applications* want, fstests uses punching to
fragment file mapping metadata and/or fragment free space, so adapt this
test for that purpose by detecting realtime files.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:41 +0000 (16:06 -0800)]
common/populate: use metadump v2 format by default for fs metadata snapshots
When we're snapshotting filesystem metadata after creating a populated
filesystem, force the creation of metadump v2 files by default to
exercise the new format, since xfs_metadump continues to use the v1
format unless told otherwise.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:40 +0000 (16:06 -0800)]
common/ext4: reformat external logs during mdrestore operations
The e2image file format doesn't support the capture of external log
devices, which means that mdrestore ought to reformat the external log
to get the restored filesystem to work again. The common/populate code
could already do this, so push it to the common ext4 helper.
While we're at it, fix the uncareful usage of SCRATCH_LOGDEV in the
populate code.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:40 +0000 (16:06 -0800)]
common/populate: refactor caching of metadumps to a helper
Hoist out of _scratch_populate_cached all the code that we use to save a
metadump of the populated filesystem. We're going to make this more
involved for XFS in the next few patches so that we can take advantage
of the new support for external devices in metadump/mdrestore.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:39 +0000 (16:06 -0800)]
xfs/509: adjust inumbers accounting for metadata directories
The INUMBERS ioctl exports data from the inode btree directly -- the
number of inodes it reports is taken from ir_freemask and includes all
the files in the metadata directory tree. BULKSTAT, on the other hand,
only reports non-metadata files. When metadir is enabled, this will
(eventually) cause a discrepancy in the inode counts that is large
enough to exceed the tolerances, thereby causing a test failure.
Correct this by counting the files in the metadata directory and
subtracting that from the INUMBERS totals.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:38 +0000 (16:06 -0800)]
xfs/{050,144,153,299,330}: update quota reports to handle metadir trees
Prior to the new metadir feature in XFS, the rtbitmap and rtsummary
files were included in icount, though their bcount contribution is zero
due to rt and quota not being supported together. With the new metadir
feature in XFS, no files in the metadata directory tree are counted in
quota.
Hence we must adjust the icount of any quota report down by two to avoid
breaking golden outputs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:38 +0000 (16:06 -0800)]
common/repair: patch up repair sb inode value complaints
Now that we've refactored xfs_repair to be more consistent in how it
reports unexpected superblock inode pointer values, we have to fix up
the fstests repair filters to emulate the old golden output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:38 +0000 (16:06 -0800)]
xfs/{030,033,178}: forcibly disable metadata directory trees
The golden output for thests tests encode the xfs_repair output when we
fuzz various parts of the filesystem. With metadata directory trees
enabled, however, the golden output changes dramatically to reflect
reconstruction of the metadata directory tree.
To avoid regressions, add a helper to force metadata directories off via
MKFS_OPTIONS.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:37 +0000 (16:06 -0800)]
various: fix finding metadata inode numbers when metadir is enabled
There are a number of tests that use xfs_db to examine the contents of
metadata inodes to check correct functioning. The logic is scattered
everywhere and won't work with metadata directory trees, so make a
shared helper to find these inodes.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Pankaj Raghav [Thu, 24 Oct 2024 11:23:11 +0000 (13:23 +0200)]
generic: increase file size to match CoW delayed allocation for XFS 64k bs
generic/305,326,328 have been failing for 32k and 64k blocksizes.
We do the following in the test 305 and 326 (highlighting only the part
that is related to failure):
- create a 1M test-1/file1
- reflink test-1/file2 and test-1/file3 based on test-1/file1
- Overwrite first half of test-1/file2 to do a CoW operation
- Expect the size of the test-1 dir to be 3M
The test is failing for 32k and 64k blocksizes as the number of blocks
(direct + delayed) is higher than number of blocks allocated for
blocksizes < 32k in XFS, resulting in size of test-1 to be more than 3M.
Though generic/328 has a different IO pattern, the reason for failure is
the same.
This is the failure output :
--- tests/generic/305.out 2024-06-05 11:52:27.430262812 +0000
+++ /root/results//64k_4ks/generic/305.out.bad 2024-10-23 10:56:57.643986870 +0000
@@ -11,7 +11,7 @@
CoW one of the files
root 0 0 0
nobody 0 0 0
-fsgqa 3072 0 0
+fsgqa 4608 0 0
Remount the FS to see if accounting changes
root 0 0 0
In these tests, XFS is doing a delayed allocation of
XFS_DEFAULT_COWEXTSIZE_HINT(32). Increase the size of the file so that
the CoW write(sz/2) matches the maximum size of the delayed allocation
for the max blocksize of 64k. This will ensure that all parts of the
delayed extents are converted to real extents for all blocksizes.
Even though this is not the most complete solution to fix these tests,
the objective of these tests are to test quota and not the effect of delayed
allocations.
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Pankaj Raghav [Thu, 24 Oct 2024 11:23:10 +0000 (13:23 +0200)]
generic/219: use filesystem blocksize while calculating the file size
generic/219 was failing for XFS with 32k and 64k blocksize. Even though
we do only 48k IO, XFS will allocate blocks rounded to the nearest
blocksize.
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chao Yu [Sat, 12 Oct 2024 01:14:19 +0000 (09:14 +0800)]
f2fs/004: add missing _fixed_by_kernel_commit line
The bug related to this regression testcase has been fixed by commit b2c160f4f3cf ("f2fs: atomic: fix to forbid dio in atomic_file"), let's
add missing _fixed_by_kernel_commit line for this testcase.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Sat, 12 Oct 2024 07:18:24 +0000 (17:48 +1030)]
fstests: btrfs/002: fix the OOM caused by too large block size
[BUG]
When running the test case btrfs/002, with 64K page size and 64K sector
size, and the VM doesn't have much memory (in my case 4G Vram), the test
case will trigger OOM and fail:
btrfs/002 4s ... [failed, exit status 1]- output mismatch (see /home/adam/xfstests-dev/results//btrfs/002.out.bad)
--- tests/btrfs/002.out 2024-04-25 18:13:45.035555469 +0930
+++ /home/adam/xfstests-dev/results//btrfs/002.out.bad 2024-10-12 17:19:48.785156223 +1030
@@ -1,2 +1 @@
QA output created by 002
-Silence is golden
...
The OOM is triggered by the dd process, and a lot of dd processes are
using too much memory:
$FSIZE is the file size, $BLKS is the size of each reported block,
$NBLK is the number of blocks the file takes, thus $FALLOC is the
rounded up block size.
For 64K sector size, the BLKS is 512, and NBLKS is 128 (one 64K sector).
$FALLOC is the correct value of 64K (10K rounded up to 64K).
In above case, since the previous file is 540M size, the output block
size will also be 540M, taking a lot of memory.
Furthermore since the workload is run in background, we can have many dd
processes taking up at least 540M, causing huge memory usage and trigger
OOM.
[FIX]
The original code is already not doing what it should do, just get rid of
the cursed dd command usage inside _fill_blk(), and use pwrite from
xfs_io instead.
Darrick J. Wong [Wed, 16 Oct 2024 23:15:48 +0000 (16:15 -0700)]
misc: amend unicode confusing name tests to check for hidden tag characters
The Unicode consortium has twice defined (and later deprecated) special
"tag" codepoints. These tag codepoints are not supposed to be rendered
(i.e. they're invisible) but you can certainly encode them in
directories and labels to try to confuse users.
xfs_scrub already knows how complain about these tag characters because
libicu can detect both their presence and their use in confusing name
attacks, so add this as an explicit regression test.
Qu Wenruo [Thu, 24 Oct 2024 10:05:03 +0000 (20:35 +1030)]
fstests: btrfs/330: enable the test case for both new and old APIs
[BUG]
If the mount tool is utilizing the new fs-based API
(e.g. util-linux 2.40.2 from Archlinux), btrfs' per-subvolume RO/RW mount
is broken again:
# mount -o subvol=subv1,ro /dev/test/scratch1 /mnt/test
# mount -o rw,subvol=subv2 /dev/test/scratch1 /mnt/scratch
# mount | grep mnt
/dev/mapper/test-scratch1 on /mnt/test type btrfs (ro,relatime,discard=async,space_cache=v2,subvolid=256,subvol=/subv1)
/dev/mapper/test-scratch1 on /mnt/scratch type btrfs (ro,relatime,discard=async,space_cache=v2,subvolid=257,subvol=/subv2)
# touch /mnt/scratch/foobar
touch: cannot touch '/mnt/scratch/foobar': Read-only file system
[CAUSE]
Btrfs has an extra remount hack to handle above case, which will
re-configure the super block to be RW on the first RW mount.
The initial promise is, the new fd-based API will not set ro FLAG, but
only MOUNT_ATTR_RDONLY, so that btrfs will skip the remount hack for new
API based mount request.
However it's not the case, the first RO subvolume mount will set ro flag
at fsconfig(), and also set MOUNT_ATTR_RDONLY attribute for the mount
point:
btrfs/012 - output mismatch (see /home/adam/xfstests-dev/results//btrfs/012.out.bad)
--- tests/btrfs/012.out 2024-10-18 10:15:29.132894338 +1030
+++ /home/adam/xfstests-dev/results//btrfs/012.out.bad 2024-10-18 10:25:51.834819708 +1030
@@ -1,6 +1,1390 @@
QA output created by 012
Checking converted btrfs against the original one:
-OK
+metadata mismatch in /p0/d2/f4
+metadata mismatch in /p0/d2/f5
+metadata and data mismatch in /p0/d2/
+metadata and data mismatch in /p0/
...
[CAUSE]
All the mismatch happens in the metadata, to be more especific, it's the
security xattrs.
Although btrfs-convert properly convert all xattrs including the
security ones, at mount time we will get new SELinux labels, causing the
mismatch between the converted and original fs.
[FIX]
Override SELINUX_MOUNT_OPTIONS so that we will not touch the security
xattrs, and that should fix the false alert.
Reported-by: Long An <lan@suse.com> Link: https://bugzilla.suse.com/show_bug.cgi?id=1231524 Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Pankaj Raghav [Wed, 16 Oct 2024 23:15:32 +0000 (16:15 -0700)]
xfs/161: adapt the test case for LBS filesystem
This test fails for >= 64k filesystem block size on a 4k PAGE_SIZE
system(see LBS efforts[1]). Adapt the blksz so that we create more than
one block for the testcase.
Cap the blksz to be at least 64k to retain the same behaviour as before
for smaller filesystem blocksizes.
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 16 Oct 2024 23:15:16 +0000 (16:15 -0700)]
common/xfs: _notrun tests that fail due to block size < sector size
It makes no sense to fail a test that failed to format a filesystem with
a block size smaller than the sector size since the test preconditions
are not valid.
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>
Mark Harmstone [Tue, 15 Oct 2024 15:39:34 +0000 (16:39 +0100)]
generic: add test for missing btrfs csums in log when doing async on subpage vol
Adds a test for a bug we encountered on Linux 6.4 on aarch64, where a
race could mean that csums weren't getting written to the log tree,
leading to corruption when it was replayed.
The patches to detect log this tree corruption are in btrfs-progs 6.11.
Signed-off-by: Mark Harmstone <maharmstone@fb.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Wed, 16 Oct 2024 17:54:33 +0000 (10:54 -0700)]
btrfs: add test for cleaner thread under seed-sprout
We have a longstanding bug that creating a seed sprout fs with the
ro->rw transition done with
mount -o remount,rw $mnt
instead of
umount $mnt
mount $sprout_dev $mnt
results in an fs without BTRFS_FS_OPEN set, which fails to ever run the
critical btrfs cleaner thread.
This test reproduces that bug and detects it by creating and deleting a
subvolume, then triggering the cleaner thread. The expected behavior is
for the cleaner thread to delete the stale subvolume and for the list to
show no entries. Without the fix, we see a DELETED entry for the subvol.
Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Boris Burkov <boris@bur.io> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 1 Oct 2024 16:49:11 +0000 (09:49 -0700)]
src/fiexchange.h: add the start-commit/commit-range ioctls
Add these two ioctls as well, since they're a part of the file content
exchange functionality.
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>
Darrick J. Wong [Thu, 10 Oct 2024 10:07:38 +0000 (18:07 +0800)]
fsstress: add support for FALLOC_FL_UNSHARE_RANGE
Teach fsstress to try to unshare file blocks on filesystems, seeing how
the recent addition to fsx has uncovered a lot of bugs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Do not allow the overwriting of the RECREATE_TEST_DEV variable. When
this variable is enabled, common/rc -> common/config will reset it
to false after the test device recreation process. This allows for
differentiation in mount options for SCRATCH and TEST.
Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Reviewed-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, 1 Oct 2024 16:48:56 +0000 (09:48 -0700)]
common/populate: fix bash syntax error in _fill_fs
In bash, one does not set a variable by prepending the dollar sign to
the variable name. Amazingly, this was copied verbatim from generic/256
in 2016 and hasn't been caught since its introduction in 2011. :(
Cc: allison.henderson@oracle.com Fixes: 815015e9ee ("generic: make 17[1-4] work well when btrfs compression is enabled") Fixes: b55fb0807c ("xfstests: Add ENOSPC Hole Punch Test") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
An Long [Fri, 11 Oct 2024 06:12:16 +0000 (14:12 +0800)]
btrfs/315: update filter to match mount cmd
Mount error info changed since util-linux v2.40
(91ea38e libmount: report failed syscall name).
So update _filter_mount_error() to match it.
Signed-off-by: An Long <lan@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 7 Oct 2024 12:02:16 +0000 (13:02 +0100)]
btrfs/322: add git commit ID
The corresponding btrfs kernel patch was merged into Linus' tree and
included in kernel 6.12-rc2, so update the test with the commit ID.
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>
Filipe Manana [Mon, 7 Oct 2024 11:32:50 +0000 (12:32 +0100)]
btrfs: update some tests to be able to run with btrfs-progs v6.11
In btrfs-progs v6.11 the output of the "filesystem show" command changed
so that it no longers prints blank lines. This happened with commit 4331bfb011bd ("btrfs-progs: fi show: remove stray newline in filesystem
show").
We have some tests that expect the blank lines in their golden output,
and therefore they fail with btrfs-progs v6.11.
So update the filter _filter_btrfs_filesystem_show to remove blank lines
and change the golden output of the tests to not expect the blank lines,
making the tests work with btrfs-progs v6.11 and older versions.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Mark Harmstone [Thu, 10 Oct 2024 15:36:25 +0000 (16:36 +0100)]
btrfs/318: add _require_loop
btrfs/318 uses loopback devices, but was missing a call to _require_loop
to print the correct message if CONFIG_LOOP is not set.
Signed-off-by: Mark Harmstone <maharmstone@fb.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Tue, 8 Oct 2024 07:12:09 +0000 (09:12 +0200)]
generic/694: sync before sampling i_blocks
Without a sync there might still be temporary blocks in i_blocks like
indirect block reservations or additional blocks reserved for out of
place writes.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hans Holmberg [Tue, 8 Oct 2024 10:52:04 +0000 (10:52 +0000)]
xfs/157,xfs/547,xfs/548: switch to using _scratch_mkfs_sized
These test cases specify small -d sizes which combined with a rt dev of
unrestricted size and the rtrmap feature can cause mkfs to fail with
error:
mkfs.xfs: cannot handle expansion of realtime rmap btree; need <x> free
blocks, have <y>
This is due to that the -d size is not big enough to support the
metadata space allocation required for the rt groups.
Switch to use _scratch_mkfs_sized that sets up the -r size parameter
to avoid this. If -r size=x and -d size=x we will not risk running
out of space on the ddev as the metadata size is just a fraction of
the rt data size.
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hans Holmberg [Tue, 8 Oct 2024 10:52:04 +0000 (10:52 +0000)]
common: make rt_ops local in _try_scratch_mkfs_sized
If we call _try_scratch_mkfs_size with $SCRATCH_RTDEV set followed by
a call with $SCRATCH_RTDEV cleared, rt_ops will have stale size
parameters that will cause mkfs.xfs to fail with:
"size specified for non-existent rt subvolume"
Make rt_ops local to fix this.
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de> 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>
fstests: generic/563: use fs blocksize to do the writes
[FALSE ALERTS]
If the system has a page size larger than 4K, and the fs block size
matches the page size, test case generic/563 will fail:
--- tests/generic/563.out 2024-04-25 18:13:45.178550333 +0930
+++ /home/adam/xfstests-dev/results//generic/563.out.bad 2024-09-30 09:09:16.155312379 +0930
@@ -3,7 +3,8 @@
read is in range
write is in range
write -> read/write
-read is in range
+read has value of 8388608
+read is NOT in range -33792 .. 33792
write is in range
...
Both Ext4 and btrfs fail with 64K block size and 64K page size
[CAUSE]
The test case writes the 8MiB file using the default block size xfs_io
pwrite, which is 4KiB.
Since the fs block size is 64K, such 4KiB write is unaligned inside a
block, causing the fs to read out the full page.
Thus the pwrite will cause the fs to read out every page, resulting the
above 8MiB+ read value.
[FIX]
Fix the test case by using the fs block size to avoid such unaligned
buffered write.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Mark Harmstone <maharmstone@fb.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
An Long [Thu, 10 Oct 2024 06:23:14 +0000 (14:23 +0800)]
src/Makefile: install two necessary files
parse-dev-tree.awk and parse-extent-tree.awk are used by generic/746.
We need to make sure them are installed, otherwise generic/746 will
have problems if fstests is installed via "make install".
Signed-off-by: An Long <lan@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
If returned parameters of statx() are: a)STATX_DIOALIGN is set in
stx_mask, b)stx.stx_dio_offset_align is zero, it indicates filesystem
supports DIO, but the file doesn't.
It needs to avoid returning zeroed stx.stx_dio_offset_align value,
instead, we can fallthrough to get alignment size of block device or
page size, otherwise, it may cause potential deadloop, e.g.
generic/465:
align=stx_dio_offset_align(it equals to zero)
page_size=4096
while [ $align -le $page_size ]; do
echo "$AIO_TEST -a $align -d $testfile.$align" >> $seqres.full
$AIO_TEST -a $align -d $testfile.$align 2>&1 | tee -a $seqres.full
align=$((align * 2))
done
Cc: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / users / hch / xfstests-dev.git / log