Filipe Manana [Tue, 3 Oct 2023 11:57:45 +0000 (12:57 +0100)]
btrfs/192: use append operator to output log replay results to $seqres.full
After doing log replay, btrfs/192 is overwriting the $seqres.full file
because it uses the plain ">" redirect operator, instead of an append
">>" redirect operator. As a consequence it is overriding the file and
eliminating any previous output that may be useful to debug a test
failure (such as the fsstress seed or mkfs results). So use >> instead
of >.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 3 Oct 2023 11:57:44 +0000 (12:57 +0100)]
fstests: redirect fsstress' stdout to $seqres.full instead of /dev/null
Several tests are redirecting the output of fsstress to /dev/null and this
makes it harder to debug a test failure because we have no way of knowing
what was the seed used by fsstress, as fsstress outputs the seed it uses
to stdout. Very often when such a test fails, I have to go modify to
redirect stdout to the $seqres.full file and then run it in a loop until
I find a seed that causes a failure.
So modify all tests that redirect fsstress' output to /dev/null to instead
redirect it to the $seqres.full file. Note that for some tests I've added
the style ">> $seqres.full" (with a space after >>) while for others I did
">>$seqres.full" (no space) - the reason for this was to keep style
consistency within each test case.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/283: skip if we cannot write into one extent
On the zoned mode, the extent size is limited also by
queue/zone_append_max_bytes. This breaks the assumption that the file "foo"
has a single extent and corrupts the test output.
It is difficult to support the case, so let's just skip the test in this
case.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Thu, 28 Sep 2023 23:16:48 +0000 (16:16 -0700)]
btrfs: skip squota incompatible tests
These tests cannot succeed if mkfs enable squotas, as they either test
the specifics of qgroups behavior or they test *enabling* squotas. Skip
these in squota mode.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Thu, 28 Sep 2023 23:16:46 +0000 (16:16 -0700)]
btrfs: quota rescan helpers
Many btrfs tests explicitly trigger quota rescan. This is not a
meaningful operation for simple quotas, so we wrap it in a helper that
doesn't blow up quite so badly and lets us run those tests where the
rescan is a qgroup detail.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Thu, 28 Sep 2023 23:16:45 +0000 (16:16 -0700)]
btrfs/301: new test for simple quotas
Test some interesting basic and edge cases of simple quotas.
To some extent, this is redundant with the alternate testing strategy of
using MKFS_OPTIONS to enable simple quotas, running the full suite and
relying on kernel warnings and fsck to surface issues.
Signed-off-by: Boris Burkov <boris@bur.io> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Thu, 28 Sep 2023 23:16:44 +0000 (16:16 -0700)]
btrfs: quota mode helpers
To facilitate skipping tests depending on the qgroup mode after mkfs,
add support for figuring out the mode. This cannot just rely on the new
sysfs file, since it might not be present on older kernels.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 22 Sep 2023 11:45:17 +0000 (12:45 +0100)]
btrfs/287: filter snapshot IDs to avoid failures when using some features
When running btrfs/287 with features that create extra trees or don't
the need to create some trees, such as when using the free space tree
(default for several btrfs-progs releases now) versus when not using
it (by passing -R ^free-space-tree in MKFS_OPTIONS), the test can fail
because the IDs for the two snapshots it creates changes, and the golden
output is requiring the numeric IDs of the snapshots.
For example, when disabling the free space tree, the test fails like this:
Filipe Manana [Fri, 22 Sep 2023 11:45:01 +0000 (12:45 +0100)]
btrfs: use full subcommand name at _btrfs_get_subvolid()
Avoid using the shortcut "sub" for the "subvolume" command, as this is the
standard practice because such shortcuts are not guaranteed to exist in
every btrfs-progs release (they may come and go). Also make the variables
local.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 21 Sep 2023 15:16:34 +0000 (16:16 +0100)]
generic: test new directory entries are returned after rewinding directory
Test that if names are added to a directory after an opendir(3) call and
before a rewinddir(3) call, future readdir(3) calls will return the names.
This is mandated by POSIX:
This exercises a regression in btrfs which is fixed by a kernel patch that
has the following subject:
""btrfs: refresh dir last index during a rewinddir(3) call""
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/239: call fsync to create tree-log dedicated block group for zoned mode
Running btrfs/239 on a zoned device often fails with the following error.
btrfs/239 5s ... - output mismatch (see /host/btrfs/239.out.bad)
--- tests/btrfs/239.out 2023-09-21 16:56:37.735204924 +0900
+++ /host/btrfs/239.out.bad 2023-09-21 18:22:45.401433408 +0900
@@ -1,4 +1,6 @@
QA output created by 239
+/testdir/dira still exists
+/dira does not exists
File SCRATCH_MNT/testdir/file1 data: 0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
*
...
This happens because "testdir" and "dira" are not logged on the first fsync
(fsync $SCRATCH_MNT/testdir), but are written as a full commit. That
prevents updating the log on "mv" time, leaving them pre-mv state.
The full commit is induced by the creation of a new block group. On the
zoned mode, we use a dedicated block group for tree-log. That block group
is created on-demand or assigned to a metadata block group if there is
none. On the first mount of a file system, we need to create one because
there is only one metadata block group available for the regular
metadata. That creation of a new block group forces tree-log to be a full
commit on that transaction, which prevents logging "testdir" and "dira".
Fix the issue by calling fsync before the first "sync", which creates the
dedicated block group and let the files be properly logged.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Thu, 21 Sep 2023 14:31:02 +0000 (17:31 +0300)]
overlay: add test for rename of lower symlink with NOATIME attr
Test for a regression in copy up of symlink that has the S_NOATIME
inode flag.
This is a regression from v5.15 reported by Ruiwen Zhao:
https://lore.kernel.org/linux-unionfs/CAKd=y5Hpg7J2gxrFT02F94o=FM9QvGp=kcH1Grctx8HzFYvpiA@mail.gmail.com/
In the bug report, the symlink has the S_NOATIME inode flag because it is
on an NFS/FUSE filesystem that sets S_NOATIME for all inodes.
The reproducer uses another technique to create a symlink with
S_NOATIME inode flag by using chattr +A inheritance on filesystems
that inherit chattr flags to symlinks.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 15 Sep 2023 09:26:50 +0000 (10:26 +0100)]
btrfs: add missing commit ids for a few tests using _fixed_by_kernel_commit
The tests btrfs/288, btrfs/289 and btrfs/300 are using the "xxxx..." stub
for commit ids, as when they were submitted/merged the corresponding
btrfs patches were not yet in Linus' tree. So replace the stubs with the
commit ids.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Running btrfs/076 on a zoned null_blk device will fail with the following error.
- output mismatch (see /host/results/btrfs/076.out.bad)
--- tests/btrfs/076.out 2021-02-05 01:44:20.000000000 +0000
+++ /host/results/btrfs/076.out.bad 2023-09-15 01:49:36.000000000 +0000
@@ -1,3 +1,3 @@
QA output created by 076
-80
-80
+83
+83
...
This is because the default value of zone_append_max_bytes is 127.5 KB
which is smaller than BTRFS_MAX_UNCOMPRESSED (128K). So, the extent size is
limited to 126976 (= ROUND_DOWN(127.5K, 4096)), which makes the number of
extents larger, and fails the test.
Instead of hard-coding the number of extents, we can calculate it using the
max extent size of an extent. It is limited by either
BTRFS_MAX_UNCOMPRESSED or zone_append_max_bytes.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Tue, 29 Aug 2023 12:32:40 +0000 (20:32 +0800)]
fstests: btrfs add more tests into the scrub group
I wanted to verify tests using the command "btrfs scrub start" and
found that there are many more test cases using "btrfs scrub start"
than what is listed in the group.list file. So, get them to the scrub
group.
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
common/rc: make _get_max_file_size find file size on mount point
Currently, _get_max_file_size finds max file size on $TEST_DIR.
The tests/generic/692 uses this function to detect file size and
then tries to create a file on $SCRATCH_MNT.
This works fine when test and scratch filesystems have the same
block size. However, it will fail if they differ.
Make _get_max_file_size accept mount point on which to detect max
file size.
Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Some test cases lack executable permission ('x'). Before running each
test case, `./check` checks and grants them 'x' permission. However,
this always leads to a dirty git repo. And the absence of 'x' permission
in test cases is often overlooked during reviews.
Since maintainers use mvtest to assign new case, add this change for
convenience of maintainers.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
fstests: btrfs/185 update for single device pseudo device-scan
As we are obliterating the need for the device scan for the single device,
which will return success if the basic superblock verification passes,
even for the duplicate device of the mounted filesystem, drop the check
for the return code in this testcase and continue to verify if the device
path of the mounted filesystem remains unaltered after the scan.
Also, if the test fails, it leaves the local non-standard mount point
remained mounted, leading to further test cases failing. Call unmount
in _cleanup().
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Sun, 3 Sep 2023 07:54:11 +0000 (10:54 +0300)]
overlay: add test for persistent unique fsid
Test overlayfs fsid behavior with new mount options uuid=null/on
that were introduced in kernel v6.6:
- Test inherited upper fs fsid with mount option uuid=off/null
- Test uuid=null behavior for existing overlayfs by default
- Test persistent unique fsid with mount option uuid=on
- Test uuid=on behavior for new overlayfs by default
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Tue, 29 Aug 2023 12:34:06 +0000 (20:34 +0800)]
fstests: btrfs/261 fix failure if /var/lib/btrfs isn't writable
We don't need scrub status; it is okay to ignore the warnings due to
the readonly /var/lib/btrfs if any. Redirect stderr to seqres.full.
We check the scrub return status.
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.42fad803-d505-48f4-a04d-612dbf8bd724: Read-only file system. Progress cannot be queried
+WARNING: failed to write the progress status file: Read-only file system. Status recording disabled
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Mon, 21 Aug 2023 09:05:09 +0000 (17:05 +0800)]
fstests: use btrfs check repair for repairing btrfs filesystems
There are two repair functions: _repair_scratch_fs() and
_repair_test_fs(). As the names suggest, these functions are designed to
repair the filesystems SCRATCH_DEV and TEST_DEV, respectively. However,
these functions never called proper comamnd for the filesystem type btrfs.
This patch fixes it. Thx.
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Aug 2023 23:03:49 +0000 (16:03 -0700)]
xfs/559: adapt to kernels that use large folios for writes
The write invalidation code in iomap can only be triggered for writes
that span multiple folios. If the kernel reports a huge page size,
scale up the write size.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Aug 2023 23:03:37 +0000 (16:03 -0700)]
common: split _get_hugepagesize into detection and actual query
This helper has two parts -- querying the value, and _notrun'ing the
test if huge pages aren't turned on. Break these into the usual
_require_hugepages and _get_hugepagesize predicates so that we can adapt
xfs/559 to large folios being used for writes.
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 [Thu, 24 Aug 2023 23:47:14 +0000 (16:47 -0700)]
btrfs/282: skip test if /var/lib/btrfs isnt writable
I run fstests in a readonly container, and accidentally uninstalled the
btrfsprogs package. When I did, this test started faililng:
--- btrfs/282.out
+++ btrfs/282.out.bad
@@ -1,3 +1,7 @@
QA output created by 282
wrote 2147483648/2147483648 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+WARNING: cannot create scrub data file, mkdir /var/lib/btrfs failed: Read-only file system. Status recording disabled
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.3e1cf8c6-8f8f-4b51-982c-d6783b8b8825: No such file or directory. Progress cannot be queried
+WARNING: cannot create scrub data file, mkdir /var/lib/btrfs failed: Read-only file system. Status recording disabled
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.3e1cf8c6-8f8f-4b51-982c-d6783b8b8825: No such file or directory. Progress cannot be queried
Skip the test if /var/lib/btrfs isn't writable, or if /var/lib isn't
writable, which means we cannot create /var/lib/btrfs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Fri, 1 Sep 2023 17:39:57 +0000 (13:39 -0400)]
generic/187: don't run this test on NFS
This test is unreliable on NFS. It fails consistently when run vs. a
server exporting btrfs, but passes when the server exports xfs. Since we
don't have any sort of attribute that we can require to test this, just
skip this one on NFS.
Also, subsume the check for btrfs into the _supported_fs check, and add
a comment for it.
Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Fri, 1 Sep 2023 17:39:56 +0000 (13:39 -0400)]
generic/357: don't run this test on NFS
NFS doesn't keep track of whether a file is reflinked or not, so it
doesn't prevent this behavior. It shouldn't be a problem for NFS anyway,
so just skip this test there.
Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Fri, 1 Sep 2023 17:39:55 +0000 (13:39 -0400)]
generic/294: don't run this test on NFS
When creating a new dentry (of any type), NFS will optimize away any
on-the-wire lookups prior to the create since that means an extra
round trip to the server. Because of that, it consistently fails this
test.
Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 30 Aug 2023 10:58:52 +0000 (06:58 -0400)]
generic/*: add a check for security attrs
There are several generic tests that require "setcap", but don't check
whether the underlying fs supports security attrs. Add the appropriate
checks.
Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 30 Aug 2023 10:58:51 +0000 (06:58 -0400)]
generic/578: add a check to ensure that fiemap is supported
This test requires FIEMAP support.
Suggested-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 30 Aug 2023 10:58:50 +0000 (06:58 -0400)]
common/attr: fix the _require_acl test
_require_acl tests whether you're able to fetch the ACL from a file
using chacl, and then tests for an -EOPNOTSUPP error return.
Unfortunately, filesystems that don't support them (like NFSv4) just
return -ENODATA when someone calls getxattr for the POSIX ACL, so the
test doesn't work.
Fix the test to have chacl set an ACL on the file instead, which should
reliably fail on filesystems that don't support them.
Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Fri, 1 Sep 2023 14:53:31 +0000 (07:53 -0700)]
generic/61[67]: support SOAK_DURATION
Now that I've finally gotten liburing installed on my test machine, I
can actually test io_uring. Adapt these two tests to support
SOAK_DURATION so I can add it to that too.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Tue, 29 Aug 2023 23:07:58 +0000 (16:07 -0700)]
generic/650: add SOAK_DURATION controls
Make this test controllable via SOAK_DURATION, for anyone who wants to
perform a long soak test of filesystem vs. cpu hotplug.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Naohiro Aota [Wed, 30 Aug 2023 02:17:52 +0000 (11:17 +0900)]
btrfs/237: kick reclaim process with a small filesystem
Since commit 3687fcb0752a ("btrfs: zoned: make auto-reclaim less
aggressive"), the reclaim process won't run unless the 75% (by default) of
the filesystem volume is allocated as block groups. As a result, btrfs/237
won't success when it is run with a large volume.
To run the reclaim process, we need to either fill the FS to the desired
level, or make a small FS so that the test write can go over the level.
Since the current test code expects the FS has only one data block group,
filling the FS is both cumbersome and need effort to rewrite the test code.
So, we take the latter method. We create a small (16 * zone size) FS. The
size is chosen to hold a minimal FS with DUP metadata setup.
However, creating a small FS is not enough. With SINGLE metadata setup, we
allocate 3 zones (one for each DATA, METADATA and SYSTEM), which is less
than 75% of 16 zones. We can tweak the threshold to 51% on regular btrfs
kernel config (!CONFIG_BTRFS_DEBUG), but that is still not enough to start
the reclaim process. So, this test requires CONFIG_BTRFS_DEBUG to set the
threshold to 1%.
Bill O'Donnell [Mon, 28 Aug 2023 17:23:07 +0000 (12:23 -0500)]
fstests: generic/352 should accomodate other pwrite behaviors
xfs_io pwrite issues a series of block size writes, but there is no
guarantee that the resulting extent(s) will be singular or contiguous.
This behavior is acceptable, but the test is flawed in that it expects
a single extent for a pwrite.
Modify test to limit pwrite and reflink to a single block.
Signed-off-by: Bill O'Donnell <bodonnel@redhat.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 23 Aug 2023 01:02:39 +0000 (18:02 -0700)]
fstests: test fix for an agbno overflow in __xfs_getfsmap_datadev
Dave Chinner reported that xfs/273 fails if the AG size happens to be an
exact power of two. I traced this to an agbno integer overflow when the
current GETFSMAP call is a continuation of a previous GETFSMAP call, and
the last record returned was non-shareable space at the end of an AG.
This is the regression test for that bug.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Naohiro Aota [Tue, 22 Aug 2023 07:28:50 +0000 (16:28 +0900)]
aio-dio-write-verify: check for the IO errors
The async write IOs can return some errors, which may lead to a short read or
corruption in io_verify() stage. Catch an error early to identify the root
cause easily.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yang Xu [Mon, 14 Aug 2023 14:41:41 +0000 (22:41 +0800)]
generic/471: Remove this broken case
I remember this case fails on last year becuase of
kernel commit cae2de69 ("iomap: Add async buffered write support")
kernel commit 1aa91d9 ("xfs: Add async buffered write support").
as below:
pwrite: Resource temporarily unavailable
wrote 8388608/8388608 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-RWF_NOWAIT time is within limits.
+pwrite: Resource temporarily unavailable
+(standard_in) 1: syntax error
+RWF_NOWAIT took seconds
So For async buffered write requests, the request will return -EAGAIN
if the ilock cannot be obtained immediately.
Here also a discussion[1] that seems generic/471 has been broken.
Now, I met this problem in my linux distribution, then I found the above
discussion. IMO, remove this case is ok and then we can avoid to meet this
false report again.
[Additional information from Dave Chinner]
We changed how timestamps are updated so that they are aware of
IOCB_NOWAIT. If the IOCB_NOWIAT DIO write now needs to update the
inode timestamps, it will return -EAGAIN instead of doing
potentially blocking operations that require IO to complete (i.e.
taking a transaction reservation).
Hence the first time we go to do a DIO read an inode, it's going to
do an atime update, which now occurrs from an IOCB_NOWAIT context
and we return -EAGAIN....
Yes, we added non-blocking timestamp updates as part of the async
buffered write support, but this was a general XFS IO path change of
behaviour to address a potential blocking point in *all* IOCB_NOWAIT
reads and writes, buffered or direct.
The test is not validating that RWF_NOWAIT is behaving correctly - it
just was a simple operation that kinda exercised RWF_NOWAIT semantics
when we had no other way to test this code. It has outlived it's
original purpose, so it should be removed...
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com> Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Note the 0/33, when the data csum mismatch triggered, it always fail
with -4 (-EINTR).
It looks like with lucky enough concurrency, we can get to the following
situation inside fsstress:
Process A | Process B
-----------------------------------+---------------------------------------
do_aio_rw() |
|- io_sumit(); |
|- io_get_events(); |
| Returned -EINTR, but IO hasn't |
| finished. |
`- free(buf); | malloc();
| Got the same memory of @buf from
| thread A.
| Modify the memory
| Now the buffer is changed while
| still under IO
This is the typical buffer modification during direct IO, which is going
to cause csum mismatch for btrfs, and btrfs properly detects it.
This is the direct cause of the problem.
The root cause is that, io_uring would use signals to handle
submission/completion of IOs.
Thus io_uring operations would interrupt AIO operations, thus causing
the above problem.
[FIX]
To fix the problem, we can just retry io_getevents() so that we can
properly wait for the IO.
This prevents us to modify the IO buffer before writeback really
finishes.
With this fixes, I can no longer reproduce the data corruption.
Naohiro Aota [Mon, 21 Aug 2023 07:12:11 +0000 (16:12 +0900)]
common/rc: introduce _random_file() helper
Currently, we use "ls ... | sort -R | head -n1" (or tail) to choose a
random file in a directory.It sorts the files with "ls", sort it randomly
and pick the first line, which wastes the "ls" sort.
Also, using "sort -R | head -n1" is inefficient. For example, in a
directory with 1000000 files, it takes more than 15 seconds to pick a file.
$ time bash -c "ls -U | sort -R | head -n 1 >/dev/null"
bash -c "ls -U | sort -R | head -n 1 >/dev/null" 15.38s user 0.14s system 99% cpu 15.536 total
$ time bash -c "ls -U | shuf -n 1 >/dev/null"
bash -c "ls -U | shuf -n 1 >/dev/null" 0.30s user 0.12s system 138% cpu 0.306 total
So, we should just use "ls -U" and "shuf -n 1" to choose a random file.
Introduce _random_file() helper to do it properly.
Lee Trager [Fri, 18 Aug 2023 08:11:56 +0000 (01:11 -0700)]
fstests: Verify dir permissions when creating a stub subvolume
btrfs supports creating nesting subvolumes however snapshots are not
recurive. When a snapshot is taken of a volume which contains a subvolume
the subvolume is replaced with a stub subvolume which has the same name and
uses inode number 2. This test validates that the stub volume copies
permissions of the original volume.
Signed-off-by: Lee Trager <lee@trager.us> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
David Disseldorp [Wed, 16 Aug 2023 10:33:30 +0000 (12:33 +0200)]
common/rc: drop 'fsck -f' parameter from _repair_test_fs
The '-f' parameter is fsck.ext# specific, where it's documented to:
Force checking even if filesystem is marked clean
_repair_test_fs() is only called on _check_test_fs() failure, so
dropping the parameter should be possible without changing ext#
behaviour.
Doing so fixes _repair_test_fs() on exfat, where fsck.exfat doesn't
support '-f'.
Signed-off-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Tue, 15 Aug 2023 08:28:35 +0000 (11:28 +0300)]
generic/{175,297,298}: fix use of uninitialized var
The truncate command in those tests use an uninitialized variable i.
in kdevops, i must contain some leftover, so we get errors like:
/data/fstests-install/xfstests/tests/generic/298: line 45: /dev/loop12):
syntax error: operand expected (error token is "/dev/loop12)")
Apparently, noone including the author of the tests knows why this
truncate command is in the test, so remove the wrong truncate command.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 14 Aug 2023 17:31:32 +0000 (20:31 +0300)]
check: fix parsing expunge file with comments
commit 60054d51 ("check: fix excluded tests are only expunged in the
first iteration") change to use exclude_tests array instead of file.
The check if a test is in expunge file was using grep -q $TEST_ID FILE
so it was checking if the test was a non-exact match to one of the
lines, for a common example: "generic/001 # exclude this test" would be
a match to test generic/001.
The commit regressed this example, because the new code checks for exact
match of [ "generic/001" == "generic/001 " ]. Change the code to match a
regular expression to deal with this case and any other suffix correctly.
NOTE that the original code would have matched test generic/100 with lines
like "generic/1000" when we get to 4 digit seqnum, so the regular
expression does an exact match to the first word of the line.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Shiyang Ruan [Mon, 14 Aug 2023 03:55:03 +0000 (11:55 +0800)]
fsx: tidy options usage and format
1. Add missing options and wrap the cli example line.
2. Cleanup and also add missing "-K" operation for options description
part.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Stas Sergeev [Tue, 1 Aug 2023 17:52:20 +0000 (22:52 +0500)]
t_ofd_locks: fix sem initialization sequence
The locker was waiting for sem_otime on sem0 to became non-zero after
incrementing sem0 himself. So sem_otime was never 0 at the time of
checking it, so the check was redundant/wrong.
This patch:
- moves the increment of sem1 to the lock-tester site
- lock-setter waits for that sem1 event, for which this patch replaces
the wait loop on sem_otime with GETVAL loop, adding a small sleep
- increment of sem0 to 2 moved past that sem1 event. That sem0 event
is currently not used/waited.
This guarantees that the lock-setter is working only after lock-getter
is fully initialized.
CC: fstests@vger.kernel.org CC: Murphy Zhou <xzhou@redhat.com> CC: Jeff Layton <jlayton@kernel.org> CC: Zorro Lang <zlang@redhat.com> Signed-off-by: Stas Sergeev <stsp2@yandex.ru> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Stas Sergeev [Tue, 1 Aug 2023 17:52:19 +0000 (22:52 +0500)]
t_ofd_locks: fix stalled semaphore handling
Currently IPC_RMID was attempted on a semid returned after failed
semget() with flags=IPC_CREAT|IPC_EXCL. So nothing was actually removed.
This patch introduces the much more reliable scheme where the wrapper
script creates and removes semaphores, passing a sem key to the test
binary via new -K option.
This patch speeds up the test ~5 times by removing the sem-awaiting
loop in a lock-getter process. As the semaphore is now created before
the test process started, there is no need to wait for anything.
CC: fstests@vger.kernel.org CC: Murphy Zhou <xzhou@redhat.com> CC: Jeff Layton <jlayton@kernel.org> CC: Zorro Lang <zlang@redhat.com> Signed-off-by: Stas Sergeev <stsp2@yandex.ru> Reviwed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Fri, 4 Aug 2023 21:34:19 +0000 (14:34 -0700)]
xfs: skip fragmentation tests when alwayscow mode is enabled, part 2
If the always_cow debugging flag is enabled, all file writes turn into
copy writes. This dramatically ramps up fragmentation in the filesystem
(intentionally!) so there's no point in complaining about fragmentation.
I missed these two in the original commit because readahead for md5sum
would create large folios at the start of the file. This resulted in
the fdatatasync after the random writes issuing writeback for the whole
large folio, which reduced file fragmentation to the point where this
test started passing.
With Ritesh's patchset implementing sub-folio dirty tracking, this test
goes back to failing due to high fragmentation (as it did before large
folios) so we need to mask these off too.
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 [Fri, 4 Aug 2023 21:17:48 +0000 (14:17 -0700)]
generic/642: fix SOAK_DURATION usage in generic/642
Misspelled variable name. Yay bash.
Fixes: 3e85dd4fe4 ("misc: add duration for long soak tests") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Luis Chamberlain [Thu, 3 Aug 2023 19:18:41 +0000 (12:18 -0700)]
fstests: add helper to canonicalize devices used to enable persistent disks
The filesystem configuration file does not allow you to use symlinks to
real devices given the existing sanity checks verify that the target end
device matches the source. Device mapper links work but not symlinks for
real drives do not.
Using a symlink is desirable if you want to enable persistent tests
across reboots. For example you may want to use /dev/disk/by-id/nvme-eui.*
so to ensure that the same drives are used even after reboot. This
is very useful if you are testing for example with a virtualized
environment and are using PCIe passthrough with other qemu NVMe drives
with one or many NVMe drives.
To enable support just add a helper to canonicalize devices prior to
running the tests.
This allows one test runner, kdevops, which I just extended with
support to use real NVMe drives it has support now to use nvme EUI
symlinks and fallbacks to nvme model + serial symlinks as not all
NVMe drives support EUIs. The drives it uses for the filesystem
configuration optionally is with NVMe eui symlinks so to allow
the same drives to be used over reboots.
For instance this works today with real nvme drives:
generic/110 2s
Ran: generic/110
Passed all 1 tests
But this does not:
TEST_DIR=/mnt TEST_DEV=/dev/disk/by-id/nvme-eui.0035385411904c1e FSTYP=xfs ./check generic/110
mount: /mnt: /dev/disk/by-id/nvme-eui.0035385411904c1e already mounted on /mnt.
common/rc: retrying test device mount with external set
mount: /mnt: /dev/disk/by-id/nvme-eui.0035385411904c1e already mounted on /mnt.
common/rc: could not mount /dev/disk/by-id/nvme-eui.0035385411904c1e on /mnt
umount /mnt
TEST_DIR=/mnt TEST_DEV=/dev/disk/by-id/nvme-eui.0035385411904c1e FSTYP=xfs ./check generic/110
TEST_DEV=/dev/disk/by-id/nvme-eui.0035385411904c1e is mounted but not on TEST_DIR=/mnt - aborting
Already mounted result:
/dev/disk/by-id/nvme-eui.0035385411904c1e /mnt
This fixes this. This allows the same real drives for a test to be
used over and over after reboots.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 26 Jul 2023 01:56:51 +0000 (18:56 -0700)]
check: generate gcov code coverage reports at the end of each section
Support collecting kernel code coverage information as reported in
debugfs. At the start of each section, we reset the gcov counters;
during the section wrapup, we'll collect the kernel gcov data.
If lcov is installed and the kernel source code is available, it will
also generate a nice html report. If a CLI web browser is available, it
will also format the html report into text for easy grepping.
This requires the test runner to set REPORT_GCOV=1 explicitly and gcov
to be enabled in the kernel.
Cc: tytso@mit.edu Cc: kent.overstreet@linux.dev Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 3 Aug 2023 11:37:46 +0000 (12:37 +0100)]
btrfs/276: make test accurate regarding number of expected extents
btrfs/276 creates a 16G file with compression enabled in order to quickly
and efficiently create a file with many extents and have a fs tree with a
height of 3 (root node at level 2), so that it can test that fiemap is
correctly reporting extent sharedness when we have shared subtrees of the
fs tree due to a snapshot.
Compression results in extents with a maximum size of 128K and the test
is expecting only extents of 128K, which normally happens if the machine
has a large amount of RAM and writeback is not triggered before the xfs_io
command finishes. However if writeback is triggered in the meanwhile, due
to memory pressure for example, then we can get end up with some extents
that are smaller than 128K, therefore increasing the total number of
extents in the test file and make the test fail.
This seems to happen often on test machines with small amounts of RAM,
such as 4G, as reported by Qu in the following thread:
So to address this create a file with holes and direct IO to make sure we
always get a specific number of extents in the test file. To speedup the
test create 2000 64K extents, with holes in between them, so that it works
on a fs with any sector size, and then create a bunch of files with large
xattrs to quickly bump the fs tree height to 3 for any node size (4K to
64K). This also guarantees that the file extent items are spread over
multiples leaves, in order to exercise fiemap's correctness when reporting
shared extents due to shared subtrees.
Reported-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Tested-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Thu, 27 Jul 2023 18:53:14 +0000 (02:53 +0800)]
fstests: add smoketest group
Darrick suggests that fstests can provide a simple smoketest, by
running several generic filesystem smoke testing for five minutes
apiece (SOAK_DURATION="5m"). Since there are only five smoke tests,
this is effectively a 20min super-quick test.
With gcov enabled, running these tests yields about ~75% coverage for
iomap and ~60% for xfs; or ~50% for ext4 and ~75% for ext4; and ~45%
for btrfs. Coverage was about ~65% for the pagecache.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 26 Jul 2023 01:57:00 +0000 (18:57 -0700)]
xfs/122: adjust test for flexarray conversions in 6.5
Adjust the output of this test to handle the conversion of flexarray
declaration conversions in linux v6.5, commit a49bbce58ea9 ("xfs:
convert flex-array declarations in xfs attr leaf blocks")
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Mon, 24 Jul 2023 15:29:27 +0000 (08:29 -0700)]
generic: add a test for device removal without dirty data
Test the removal of the underlying device when the file system still
does not have dirty data.
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>
Christoph Hellwig [Mon, 24 Jul 2023 15:29:26 +0000 (08:29 -0700)]
generic: add a test for device removal with dirty data
Test the removal of the underlying device when the file system still
has dirty data.
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>
btrfs: add a test case to make sure scrub can repair parity corruption
There is a kernel regression caused by commit 75b470332965 ("btrfs:
raid56: migrate recovery and scrub recovery path to use error_bitmap"),
which leads to scrub not repairing corrupted parity stripes.
So here we add a test case to verify the P/Q stripe scrub behavior by:
- Create a RAID5 or RAID6 btrfs with minimal amount of devices
This means 2 devices for RAID5, and 3 devices for RAID6.
This would result the parity stripe to be a mirror of the only data
stripe.
And since we have control of the content of data stripes, the content
of the P stripe is also fixed.
- Create an 64K file
The file would cover one data stripe.
- Corrupt the P stripe
- Scrub the fs
If scrub is working, the P stripe would be repaired.
Unfortunately scrub can not report any P/Q corruption, limited by its
reporting structure.
So we can not use the return value of scrub to determine if we
repaired anything.
- Verify the content of the P stripe
- Use "btrfs check --check-data-csum" to double check
By above steps, we can verify if the P stripe is properly fixed.
Commit 3e85dd4fe423 ("misc: add duration for long soak tests") added a
helper executable, soak_duration.awk, is which used by the check
script if SOAK_DURATION is set. This script translates a
"human-friendly" time duration specifier, such as 4m or 2d into an
integer number of seconds. We need to make sure that this script is
installed or the check script will bomb out if SOAK_DURATION is set
(and if the fstests installation doesn't include a full set of fstests
source, but just those files installed by "make install").
Fixes: 3e85dd4fe423 ("misc: add duration for long soak tests") Cc: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Theodore Ts'o <tytso@mit.edu> 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 [Fri, 13 Jan 2023 07:06:53 +0000 (15:06 +0800)]
btrfs: add a test case to verify that per-fs features directory gets updated
Although btrfs has a per-fs feature directory, it's not properly
refreshed after new features are enabled.
We had some attempts to do that properly, like commit 14e46e04958d
("btrfs: synchronize incompat feature bits with sysfs files").
But unfortunately that commit get later reverted as some call sites is
not safe to update sysfs files.
Now we have a new commit b7625f461da6 ("btrfs: sysfs: update fs features
directory asynchronously") to properly refresh that per-fs features
directory.
So it's time to add a test case for it. The test case itself is pretty
straightforward:
- Make a very basic 3 disks btrfs
Only using the very basic profiles (DUP/SINGLE) so that even older
mkfs.btrfs can support.
- Make sure per-fs features directory doesn't contain "raid1c34" file
- Balance the metadata to RAID1C3 profile
- Verify the per-fs features directory contains "raid1c34" feature file
Qu Wenruo [Sat, 25 Feb 2023 09:14:38 +0000 (17:14 +0800)]
btrfs: add a test case to check btrfs won't crash on certain corruption
The test case would reproduce the situation by creating an empty fs,
with SINGLE metadata profile, then corrupt the tree root manually.
Finally try mounting the corrupted fs, the mount should fail while our
kernel should not fail.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com>
[ Update commit log. Fix a line gt 80 chars. Use append to $seqres.full.
Fix comment ] Signed-off-by: Anand Jain <anand.jain@oracle.com>
Darrick J. Wong [Wed, 19 Jul 2023 01:10:47 +0000 (18:10 -0700)]
generic/558: avoid forkbombs on filesystems with many free inodes
Mikulas reported that this test became a forkbomb on his system when he
tested it with bcachefs. Unlike XFS and ext4, which have large inodes
consuming hundreds of bytes, bcachefs has very tiny ones. Therefore, it
reports a large number of free inodes on a freshly mounted 1GB fs (~15
million), which causes this test to try to create 15000 processes.
There's really no reason to do that -- all this test wanted to do was to
exhaust the number of inodes as quickly as possible using all available
CPUs, and then it ran xfs_repair to try to reproduce a bug. Set the
number of subshells to 4x the CPU count and spread the work among them
instead of forking thousands of processes.
Reported-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Tested-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Fri, 14 Jul 2023 14:57:05 +0000 (07:57 -0700)]
xfs: add a couple more tests for ascii-ci problems
Add some tests to make sure that userspace and the kernel actually
agree on how to do ascii case-insensitive directory lookups, and that
metadump can actually obfuscate such filesystems.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
I've spent a non-negligible amount of time looking into a kmemleak that
didn't exist in the code I was testing because there was an old .kmemleak
file in the results directory. I don't think this is an intended behaviour,
so I'm proposing to remove these files everytime we capture the result of a
new scan.
Signed-off-by: Luís Henriques <lhenriques@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Alexander Larsson [Mon, 10 Jul 2023 09:07:13 +0000 (11:07 +0200)]
overlay: Add test coverage for fs-verity support
This tests that the right xattrs are set during copy-up, and
that we properly fail on missing of erronous fs-verity digests
when validating.
We also ensure that verity=require fails if a metacopy has not
fs-verity, and doesn't do a meta-coopy-up if the base file lacks
verity.
Signed-off-by: Alexander Larsson <alexl@redhat.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 10 Jul 2023 09:07:12 +0000 (11:07 +0200)]
overlay: Add test for follow of lowerdata in data-only layers
Add test coverage for following metacopy from lower layer to
data-only lower layers.
Data-only lower layers are configured using the syntax:
lowerdir=<lowerdir1>:<lowerdir2>::<lowerdata1>::<lowerdata2>.
Test that lowerdata files can be followed only by absolute redirect
from lower layer.
Test that with two lowerdata dirs, we can lookup individual lowerdata
files in both, and that a shared file is resolved from the uppermost
lowerdata dir.
There is also test case for lazy-data lookups, where we remove the
lowerdata file and validate that we get metadata from the metacopy
file, but open fails.
Signed-off-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 10 Jul 2023 09:07:11 +0000 (11:07 +0200)]
overlay/060: add test cases of follow to lowerdata
Add test coverage for following metacopy from lower layer to
lower data with absolute, relative and no redirect.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Alexander Larsson <alexl@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 10 Jul 2023 09:07:10 +0000 (11:07 +0200)]
overlay: add helper for mounting rdonly overlay
Allow passing empty upperdir to _overlay_mount_dirs().
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Alexander Larsson <alexl@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
By specifying "xmlns=https://git.kernel.org/.../xfstests-dev.git",
this causes XML complaint parsers, such as the one used by the python
junitparser library, to put all of the XML elements into a namespace,
which then causes junitparser to toss its cookies.
This can be worked-around in a test runner script via:
sed -i.orig -e 's/xmlns=\".*\"//' "$RESULT_BASE/result.xml"
but it's better not to include the xmlns line at all in the first
place, since this may cause other users of fstests who are using
the Python junitparser library a lot of headaches.
Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
After every single test, we rewrite result.xml from scratch. This
ensures that the XML file is always in a valid, parseable state, even
if the check script is killed or the machine crashes in the middle of
a test.
If the test is being run in a Cloud VM as a "spot" (Amazon, Azure, or
GCE) or "preemptible" (Oracle) instance, the VM can be halted whenever
the Cloud provider needs the capacity for customers who are willing to
pay full price. ("Spot" instances can be 60% to 90% cheaper ---
allowing the frugal kernel developer to get up to 10 times more
testing for the same amount of money. :-)
Since a "spot" VM can get terminated at any time, it is possible for
the check script to be killed while it is in the middle of rewriting
the result.xml file. If the result.xml file is only partially
written, information regarding the tests run before VM termination
will be lost.
To address this race, write the new result.xml file as result.xml.new,
and only rename it to result.xml after the XML file is fully written
out.
Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 3 Jul 2023 17:03:44 +0000 (10:03 -0700)]
xfs/569: skip post-test fsck run
This test examines the behavior of mkfs.xfs with specific filesystem
configuration files by formatting the scratch device directly with those
exact parameters. IOWs, it doesn't include external log devices or
realtime devices. If external devices are set up, the post-test fsck
run fails because the filesystem doesnt' use the (allegedly) configured
external devices. Fix that by adding _require_scratch_nocheck.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
The test injects the bmap_alloc_minlen_extent error, which refuses to
allocate file space unless it's exactly minlen long. However, a
precondition of this injection point is that the free space on the data
device must be sufficiently fragmented that there are small free
extents.
However, if realtime and rtinherit are enabled, the punch-alternating
call will operate on a realtime file, which only serves to write 0x55
patterns into the realtime bitmap. Hence the test preconditions are not
satisfied, so the test is not serving its purpose.
Fix it by disabling rtinherit=1 on the rootdir so that we actually
fragment the bnobt/cntbt as required.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Thu, 29 Jun 2023 00:10:10 +0000 (08:10 +0800)]
common/btrfs: handle dmdust as mounted device in _btrfs_buffered_read_on_mirror()
[BUG]
After commit ab41f0bddb73 ("common/btrfs: use _scratch_cycle_mount to
ensure all page caches are dropped"), the test case btrfs/143 can fail
like below:
btrfs/143 6s ... [failed, exit status 1]- output mismatch (see ~/xfstests/results//btrfs/143.out.bad)
--- tests/btrfs/143.out 2020-06-10 19:29:03.818519162 +0100
+++ ~/xfstests/results//btrfs/143.out.bad 2023-06-19 17:04:00.575033899 +0100
@@ -1,37 +1,6 @@
QA output created by 143
wrote 131072/131072 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
[CAUSE]
Test case btrfs/143 uses dm-dust device to emulate read errors, this
means we can not use _scratch_cycle_mount to cycle mount $SCRATCH_MNT.
As it would go mount $SCRATCH_DEV, not the dm-dust device to
$SCRATCH_MNT.
This prevents us to trigger read-repair (since no error would be hit)
thus fail the test.
[FIX]
Since we can mount whatever device at $SCRATCH_MNT, we can not use
_scratch_cycle_mount in this case.
Instead implement a small helper to grab the mounted device and its
mount options, and use the same device and mount options to cycle
$SCRATCH_MNT mount.
This would fix btrfs/143 and hopefully future test cases which use dm
devices.
Reported-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 20 Jun 2023 12:00:21 +0000 (13:00 +0100)]
btrfs: test activating swapfile in the presence of snapshots
Test that if we have a subvolume with a non-active swap file, we can not
activate it if there are any snapshots. Also test that after all the
snapshots are removed, we will be able to activate the swapfile.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Sun, 18 Jun 2023 12:45:06 +0000 (15:45 +0300)]
generic/604: Fix for overlayfs
Since v6.3, I noticed that generic/604 does not run on overlayfs
because:
generic/604 -- upper fs needs to support d_type
This is odd because the base fs I am using (xfs) does support d_type.
The reason is that for overlayfs, this sequence run by this test:
_scratch_unmount &
_scratch_mount
Translates to:
umount $OVL_MNT; umount $BASE_MNT &
mount $BASE_MNT ...; mount $OVL_MNT ...
Which can end up reordred as:
umount $OVL_MNT;
mount $BASE_MNT ...
umount $BASE_MNT &
mount $OVL_MNT ...
and overlayfs is trying to use a non-existing upper fs.
Use UMOUNT_PROG directly instead of the _scratch_unmount
helper, to avoid unmounting the base fs.
Incidently, the only thing that has changed in overlayfs in v6.3
is idmapped mounts support and the test in question was run without
idmapped mounts enabled, so the cahnge in behavior must be related
to some subtle timing change.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yuezhang Mo [Tue, 4 Jul 2023 23:49:55 +0000 (07:49 +0800)]
check: fix excluded tests are only expunged in the first iteration
If iterating more than once and excluding some tests, the
excluded tests are expunged in the first iteration, but run in
subsequent iterations. This is not expected.
The problem was caused by the temporary file saving the excluded
tests being deleted by `rm -f $tmp.*` in _wrapup() at the end of
the first iteration.
This commit saves the excluded tests into a variable instead of a
temporary file.
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@foxmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 19 Jun 2023 10:50:58 +0000 (13:50 +0300)]
fstests: reduce runtime of check -n
kvm-xfstests invokes check -n twice to pre-process and generate the
tests-to-run list, which is then being passed as a long list of tests
for invkoing check in the command line.
check invokes dirname, basename and sed several times per test just
for doing basic string prefix/suffix trimming.
Use bash string pattern matching instead which is much faster.
Note that the following pattern matching expression change:
< test_dir=${test_dir#$SRC_DIR/*}
> t=${t#$SRC_DIR/}
does not change the meaning of the expression, because the
shortest match of "$SRC_DIR/*" that is being trimmed is "$SRC_DIR/"
and removing the tests/ prefix is what this code intended to do.
With check -n, there is no need to cleanup the results dir,
but check -n is doing that for every single listed test.
Move the cleanup of results dir to before actually running the test.
These improvements to check pre-test code cut down several minutes
from the time until tests actually start to run with kvm-xfstests.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Carlos Maiolino [Wed, 24 May 2023 13:42:07 +0000 (15:42 +0200)]
common/rc: Enable _test_mkfs to force a mkfs on a xfs filesystem
Calling _test_mkfs on an already initialized xfs FS will fail as the
initialization is not enforced by '-f' argument, unless it's included in
MKFS_OPTIONS.
So, adding 'RECREATE_TEST_DEV=true' to the config file end up being useless
for xfs filesystems.
So, adding the a specific xfs optiong in _test_mkfs using -f argument
makes RECREATE_TEST_DEV actually useful.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Xiubo Li [Thu, 1 Jun 2023 02:52:07 +0000 (10:52 +0800)]
common/rc: skip ceph-fuse when atime is required
Ceph won't maintain the atime, so just skip the tests when the atime
is required.
Fixes: https://tracker.ceph.com/issues/61551 Signed-off-by: Xiubo Li <xiubli@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / users / hch / xfstests-dev.git / log