Mmap 2 pages of file, write 64 bytes to the first and second pages,
copy the data from the first page and then second page to the second
page offset with $pagesize - 64. Verify the data at the end.
+-----------------------+
| (copy) |
| V
+---------------+---------------+------------
|AAAA| ........ |AAAA| ... |AAAA|AAAA|
+---------------+---------------+------------
| ^
| (copy) |
+------------+
This's also a regression test cover kernel commit: 4f06dd92b5d0
("fuse: fix write deadlock")
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check wiping of dir entry data upon removing a file, converting to an
htree, and splitting htree nodes.
Tests commit 6c0912739699d8e4b6a87086401bf3ad3c59502d ("ext4: wipe
ext4_dir_entry2 upon file deletion").
Signed-off-by: Leah Rumancik <leah.rumancik@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
When running btrfs/215 with 64K page size, 4K sectorsize (subpage RW
support), it fails with the following error:
btrfs/215 [failed, exit status 1]- output mismatch (see ~/xfstests-dev/results//btrfs/215.out.bad)
--- tests/btrfs/215.out 2021-03-19 16:34:26.069634953 +0800
+++ ~/xfstests-dev/results//btrfs/215.out.bad 2021-05-17 16:52:34.743514224 +0800
@@ -1,2 +1,3 @@
QA output created by 215
-Silence is golden
+Errors: 8 expected: 2
+(see ~/xfstests-dev/results//btrfs/215.full for details)
...
(Run 'diff -u ~/xfstests-dev/tests/btrfs/215.out ~/xfstests-dev/results//btrfs/215.out.bad' to see the entire diff)
[CAUSE]
For subpage case, btrfs still tries to read the full page, other than
read just one sector for PAGE_SIZE == sectorsize case.
This means for the 2 sectors corrupted case, since they are in the same
page, all the errors will be reported.
[FIX]
Change the following values:
- filesize
Now it's 8 * pagesize.
- expected error number
Now it's 2 * sectors_per_page or 6 * sectors_per_page.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This program fails on filesystems where the stat() block size isn't a
strict power of two because it foolishly feeds that to posix_memalign to
allocate an aligned memory buffer for directio. posix_memalign requires
the alignment value to be a power of two, so generic/586 fails.
The system page size generally works well for directio buffers, so use
that instead.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Fix the obviously incorrect code here that wants to fail the test if
mkfs doesn't succeed. The return value ("$?") is always the status of
the /last/ command in the pipe.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>