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>
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>
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>
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>
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>
A previous update to this test dropped the clause where the mkfs
standard output gets sent to /dev/null. The filtered mkfs output isn't
needed here and it breaks the test, so fix that.
Fixes: e97f96e5 ("xfs/27[26]: force realtime on or off as needed")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test case 631 fails for filesystems like exfat or vfat or any other
which does not support extended attributes.
The main reason for failure is not being able to mount overlayfs
with filesystems that do not support extended attributes.
mount -t overlay overlay -o "$l,$u,$w,$i" $mergedir
Above command would return an error as -
/var/mnt/scratch/merged0: wrong fs type, bad option, bad superblock
on overlay, missing codepage or helper program, or other error.
dmesg log reports the following -
overlayfs: filesystem on '/var/mnt/scratch/upperdir1' not supported
As per the overlayfs documentation -
"A wide range of filesystems supported by Linux can be the lower
filesystem, but not all filesystems that are mountable by Linux
have the features needed for OverlayFS to work. The lower filesystem
does not need to be writable. The lower filesystem can even be another
overlayfs. The upper filesystem will normally be writable and if it
is it must support the creation of trusted.* and/or user.* extended
attributes, and must provide valid d_type in readdir responses,
so NFS is not suitable. A read-only overlay of two read-only
filesystems may use any filesystem type."
As per the above statements from the overlayfs documentation,
it is clear that filesystems that do not support extended
attributes or d_type would not work with overlayfs.
This is why we see the error in dmesg log for upperdir1
which had an exfat filesystem.
This test case already checks for d_type but does not check for
extended attributes, hence add a check for it which would avoid
running this tests for filesystems that are not supported.
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure that we can reset the root directory and the xattrs are erased
properly.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since we're adding to xfs_repair the ability to warn about bad finobt
levels, filter that out.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Leah Rumancik
Qu Wenruo
Darrick J. Wong
Sidong Yang
Jinhui Huang
Filipe Manana
Gao Xiang
Anand Jain
Amir Goldstein
Shreeya Patel