The block sizes reported by stat and DIOINFO aren't required to be
powers of two. This can happen on an XFS filesystem with a realtime
extent size that isn't a power of two; on such filesystems, certain IO
calls will fail due to alignment issues. Fix that by providing rounding
helpers that work for all sizes.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This fuzz test has some fragility problems -- it doesn't do anything to
guarantee that the inodes that it checks for EFSCORRUPTED are the same
ones that it fuzzed, and it doesn't explicitly try to avoid victimizing
inodes in the same chunk as the root directory. As a result, this test
fails annoyingly frequently.
Fix both of these problems and get rid of the confusingly named TESTDIR
variable.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
I found a bunch more tests in the xfs/ directory that try to create
specific metadata layouts on the data device, either because they're
fuzz tests or because they're testing specific edge cases of the code
base. Either way, these test need to override '-d rtinherit' in the
MKFS_OPTIONS, so do that with _xfs_force_bdev.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Refactor all the places where we try to force new file data allocations
to a specific xfs backing device so that we don't end up open-coding the
same xfs_io command lines over and over.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test failed when scratch device don't have enough space for
copying files. This patch gets size of files by du command and
checks if there is enough space in the device.
Signed-off-by: Sidong Yang <realwakka@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
1.xfs/162 uses xfs_db -c 'fuzz' but forgets to check if the feature
is supported. This will cause the case to fail on a system without
fuzz support. so we add _require to check if the fuzz is supported.
2.xfs/495 use _require_scratch_xfs_fuzz_fields to check the features
required by field fuzzing, but some of the features are not used in
this case like xfs_scrub, this will cause the case to skip on a system
without xfs_scrub support, even if the features being uesd are supported.
So we just need to use _require to check the features being used.
Signed-off-by: Jinhui Huang <huangjh.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test a particular scenario where we fsync a directory, then move one of
its children directories into another directory and then finally sync the
log trees by fsyncing any other inode. We want to check that after a power
failure we are able to mount the filesystem and that the moved directory
exists only as a child of the directory we moved it into.
This currently fails on a 5.12 kernel (and 5.13-rc1) but is fixed by a
patch with the following subject:
"btrfs: fix removed dentries still existing after log is synced"
The failure is due to ending up with a directory that has 2 hard links
(two parent directories) as soon as the log replay procedure finishes,
which causes the tree checker to detect the issue and cause the mount
operation to fail with -EIO.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If fsx encounters a situation where copy_file_range reports that it
copied more than it was asked to, we report this as a failure.
Unfortunately, the parameters to the print function are backwards,
leading to this bogus complaint about a short copy:
do_copy_range: asked 28672, copied 24576??
When we really asked to copy 24k but 28k was copied instead.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If the test runner gave us the name of a program to use to compress
dumps, always pass -f to overwrite older compressed images, like the
documentation says we do. This prevents the test suite from stalling on
"foo.md.gz exists, overwrite?" prompts.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some of the older blocktrash-based fuzz tests cause the fs to go down
due to the corrupted image and fail to remount. Offline repair fails
because _repair_scratch_fs is the helper that is smart enough to call
xfs_repair -L, not _scratch_xfs_repair. Fix these instances.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This adds a stress testcase to shrink free space as much as
possible in the last AG with background fsstress workload.
The expectation is that no crash happens with expected output.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When running btrfs/187 with a bash 5.0+ build that has debug enabled, the
test fails due to an unexpected warning message from bash:
$ ./check btrfs/187
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian9 5.12.0-rc8-btrfs-next-92 #1 SMP PREEMPT Wed Apr 21 10:36:03 WEST 2021
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/187 436s ... - output mismatch (see /xfstests/results//btrfs/187.out.bad)
--- tests/btrfs/187.out 2020-10-16 23:13:46.550152492 +0100
+++ /xfstests/results//btrfs/187.out.bad 2021-04-27 14:57:02.623941700 +0100
@@ -1,3 +1,4 @@
QA output created by 187
Create a readonly snapshot of 'SCRATCH_MNT' in 'SCRATCH_MNT/snap1'
Create a readonly snapshot of 'SCRATCH_MNT' in 'SCRATCH_MNT/snap2'
+/xfstests/tests/btrfs/187: line 1: warning: wait_for: recursively setting old_sigint_handler to wait_sigint_handler: running_trap = 16
...
(Run 'diff -u /xfstests/tests/btrfs/187.out /xfstests/results//btrfs/187.out.bad' to see the entire diff)
Ran: btrfs/187
Failures: btrfs/187
Failed 1 of 1 tests
This is because the process running dedupe_files_loop() executes the 'wait'
command in the trap it has setup and very often it receives the SIGTERM
signal while it is running the 'wait' command in the while loop of that
function - so executing the trap makes bash run 'wait' while it is already
running 'wait', triggering the warning message from bash.
That warning message was added in bash 5.0 by commit 36f89ff1d8b761
("SIGINT trap handler SIGINT loop fix"):
https://git.savannah.gnu.org/cgit/bash.git/commit/?id=36f89ff1d8b761c815d8993e9833e6357a57fc6b
So fix this by making the trap set a local variable named 'stop' to the
value 1 and have the loop exit when the local variable 'stop' is 1.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for kernel commit 65cd913ec9d9
("ovl: invalidate readdir cache on changes to dir with origin")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check that directory modifications to an open dir fd are observed
by a new open fd.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Will be used to test missing/stale entries after modifications to
an open dirfd.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Prior to lazysbcount, the xfs mount code blindly trusted the value of
the fdblocks counter in the primary super, which means that the kernel
doesn't detect the fuzzed fdblocks value at all. V4 is deprecated and
pre-lazysbcount V4 hasn't been the default for ~14 years, so we'll just
skip these two tests on those old filesystems.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test exercises xfs_db functionality that relates to the free space
btrees on the data device. Therefore, make sure that the files we
create are not realtime files.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is yet another one of those tests that looks at what happens when
we run out of space for more metadata (in this case, xattrs). Make sure
that the 256M we write to the file to try to stimulate ENOSPC gets
written to the same place that xfs puts xattr data -- the data device.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Sidong Yang
Jinhui Huang
Filipe Manana
Gao Xiang
Anand Jain
Amir Goldstein