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>
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>
DAX doesn't support swapfile. Without this patch,
_require_scratch_swapfile always returns fail for fsdax. Now
change to notrun.
Fixes: 725feeff ("common/rc: swapon should not fail for given FS in _require_scratch_swapfile()")
Signed-off-by: Xiaoli Feng <xifeng@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In commit 725feeff, I forgot that xfs has *not* always supported all
swap file configurations -- the bmap swapfile activation prior to the
introduction of iomap_swapfile_activate did not permit the use of
unwritten extents in the swap file. Therefore, kick xfs out of the
always-supported list.
Fixes: 725feeff ("common/rc: swapon should not fail for given FS in _require_scratch_swapfile()")
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 the advent of iomap_swapfile_activate in XFS, we actually /do/
support having swap files on the realtime device. Remove this test.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a test for commit 18bb8bbf13c1 ("btrfs: zoned: automatically
reclaim zones").
This test creates a two file on a newly created FS in a way that
when we delete the first one, an auto reclaim process will be
triggered by the FS.
After the reclaim process, it verifies that the data was moved to
another zone and old zone was successfully reset.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Gao Xiang
Filipe Manana
Anand Jain
Amir Goldstein
Shreeya Patel
Xiaoli Feng
Johannes Thumshirn