Darrick J. Wong [Tue, 27 Oct 2020 19:01:42 +0000 (12:01 -0700)]
xfs/520: disable external devices
This is a regression test for a specific bug that requires a specific
configuration of the data device. Realtime volumes and external logs
don't affect the efficacy of the test, but the test can fail mkfs if the
realtime device is very large.
Therefore, unset USE_EXTERNAL so that we always run this regression
test, even if the tester enabled realtime.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Wed, 4 Nov 2020 11:13:37 +0000 (11:13 +0000)]
generic: test number of blocks used by a file after mwrite into a hole
Test that after doing a memory mapped write to an empty file, a call to
stat(2) reports a non-zero number of used blocks.
This is motivated by a bug in btrfs where the number of blocks used does
not change. It currenly fails on btrfs and it is fixed by a patch that
has the following subject:
"btrfs: fix missing delalloc new bit for new delalloc ranges"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Josef Bacik [Wed, 4 Nov 2020 20:38:45 +0000 (15:38 -0500)]
btrfs/220: fix how we tests for mount options
Filipe noticed that btrfs/220 started failing with some mount option
changes I made recently, but upon closer inspection this test actually
fails in a lot of different ways normally, specifically if you specify
MOUNT_OPTIONS, or if you make an fs with the free space tree.
Address all these issues by reworking how we test that the mount options
are what we expect. First get what the default mount options are for a
plain mount of SCRATCH_DEV. This is used as the baseline, so no matter
how the mount options change in the future it will always work properly.
Secondly instead of specifying a rigid order of the mount options we're
testing, which breaks if we adjust the order in /proc/self/mounts,
simply specify the options we're actually interested in checking. Then
in the test function combine the common options with the new options
we're testing, and then combine that with our actual options and use
some sort magic to see if there's any difference. If there's no
difference then we know we have everything set as expected, if not we
fail.
This patch addresses the initial issue that Filipe noticed, but also
fixes the failures when you specified MOUNT_OPTIONS, or if you made the
fs with the free space tree.
Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Biggers [Sun, 1 Nov 2020 17:16:19 +0000 (09:16 -0800)]
tests/ceph: add Makefile
'make install' stopped working because the tests/ceph/ directory is
missing a Makefile. Add it.
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Bill O'Donnell <billodo@redhat.com> Reviewed-by: Vladimir Zapolskiy <vladimir@tuxera.com> Tested-by: Vladimir Zapolskiy <vladimir@tuxera.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Biggers [Sat, 31 Oct 2020 07:23:44 +0000 (00:23 -0700)]
generic: test that encryption nonces are unique and random
Test that encryption nonces are unique and random, where randomness is
approximated as "incompressible by the xz program".
This gets indirectly tested by generic/399, but there are some gaps.
It's good to test for this directly too.
This test runs and passes on ext4 and f2fs. It doesn't currently run on
ubifs because _get_encryption_nonce() isn't implemented for ubifs yet.
(At some point I'll probably switch _get_encryption_nonce() to use
FS_IOC_GET_ENCRYPTION_NONCE, which was added in Linux 5.7. But for now
I'd like to keep the tests using it runnable on older kernels too.)
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Biggers [Sat, 31 Oct 2020 05:41:41 +0000 (22:41 -0700)]
generic/398: remove workarounds for wrong error codes
generic/398 contains workarounds to allow for renames of encrypted files
to fail with different error codes. However, these error codes were
fixed up by kernel commits f5e55e777cc9 ("fscrypt: return -EXDEV for
incompatible rename or link into encrypted dir") and 0c1ad5242d4f
("ubifs: switch to fscrypt_prepare_rename()").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Biggers [Sat, 31 Oct 2020 05:40:18 +0000 (22:40 -0700)]
generic/395: remove workarounds for wrong error codes
generic/395 contains workarounds to allow for some of the fscrypt ioctls
to fail with different error codes. However, the error codes were all
fixed up and documented years ago:
- FS_IOC_GET_ENCRYPTION_POLICY on ext4 failed with ENOENT instead of
ENODATA on unencrypted files. Fixed by commit db717d8e26c2
("fscrypto: move ioctl processing more fully into common code").
- FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of EEXIST
on encrypted files. Fixed by commit 8488cd96ff88 ("fscrypt: use
EEXIST when file already uses different policy").
- FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of ENOTDIR
on nondirectories. Fixed by commit dffd0cfa06d4 ("fscrypt: use
ENOTDIR when setting encryption policy on nondirectory").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Biggers [Sat, 31 Oct 2020 05:41:29 +0000 (22:41 -0700)]
generic/397: remove workarounds for wrong error codes
generic/397 contains workarounds to allow for kernel bugs where trying
to open or create files in an encrypted directory without the encryption
key failed with ENOENT, EACCES, or EPERM instead of the expected ENOKEY.
However, all these bugs have been fixed. ext4 and f2fs were fixed years
ago by commit 54475f531bb8 ("fscrypt: use ENOKEY when file cannot be
created w/o key"). ubifs was fixed by commit b01531db6cec ("fscrypt:
fix race where ->lookup() marks plaintext dentry as ciphertext").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Thu, 29 Oct 2020 12:09:06 +0000 (12:09 +0000)]
fstests: add missing remove of the $seqres.full file for some tests
Some test cases are missing the 'rm -f $seqres.full' line but are appending
to that file, so everytime they run that file gets bigger and bigger (some
of them are using about a dozen megabytes on one of my test boxes).
So just add the 'rm -f $seqres.full' line to them, together with the comment
that the 'new' script generates for new test cases.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Xiao Yang [Tue, 27 Oct 2020 02:52:11 +0000 (10:52 +0800)]
ext4: Add a test for inline_data vs. DAX inode flag
Inline_data is mutually exclusive to DAX inode flag so enabling both
of them is not expected and triggers some errors. It's a regression
test for kernel commit aa2f77920b74 ("ext4: disallow modifying DAX
inode flag if inline_data has been set")
Luis Henriques [Mon, 19 Oct 2020 13:27:49 +0000 (14:27 +0100)]
ceph: test combination of copy_file_range with truncate
This tests a bug found while testing copy_file_range. This bug was an
issue with how the OSDs handled the truncate_seq value, which was being
copied from the original object into the destination object. This test
ensures the kernel client correctly handles fixed/non-fixed OSDs.
Test remote copy operation (CEPH_OSD_OP_COPY_FROM) with different
combinations of both object sizes and copy sizes.
Test remote copy operation (CEPH_OSD_OP_COPY_FROM) with several
combinations of both object sizes and copy sizes. It also uses several
combinations of copy ranges. For example, copying the 1st object in the
src file into:
1) the beginning (1st object) of dst file,
2) the end (last object) of dst file and
3) the middle of the dst file.
Ritesh Harjani [Thu, 22 Oct 2020 12:16:32 +0000 (17:46 +0530)]
ext4: verify unwritten extent conversion in buff-io
There was an issue where with filesize > 4G, map.m_lblk
was getting overflow in buff-IO path while converting unwritten to
written extent with dioread_nolock mount option with bs < ps.
Adding a testcase to test for such regressions with dioread_nolock
mount option. To reproduce the same regression w/o the fix
in the kernel, test with bs < ps config.
The following commit fixed the issue in linux.
id1e18b8824dd ("ext4: fix bs < ps issue reported with dioread_nolock
mount opt")
Filipe Manana [Tue, 20 Oct 2020 14:43:01 +0000 (15:43 +0100)]
btrfs: add test case for rwf_nowait writes
Test several scenarios for RWF_NOWAIT writes, to verify we don't regress
on btrfs specific behaviour (snapshots, cow files, reflinks, holes,
prealloc extent beyond eof).
We had some bugs in the past related to RWF_NOWAIT writes not failing on
btrfs when they should or failing when they shouldn't, these were fixed by
the following kernel commits:
4b1946284dd6 ("btrfs: fix failure of RWF_NOWAIT write into prealloc extent beyond eof") 260a63395f90 ("btrfs: fix RWF_NOWAIT write not failling when we need to cow")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When nfs_export is enabled, the link count of upper dir
objects are more then the expected number in this testcase.
Because extra index entries are linked to upper inodes.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Matthew Wilcox [Mon, 19 Oct 2020 12:58:39 +0000 (13:58 +0100)]
generic/127: to exit if any subtest fails
If one of the subtests of generic/127 fails, we proceed with the
rest of the tests, potentially overwriting useful data. This makes
it stop as soon as any of the subtests fails.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Josef Bacik [Tue, 15 Sep 2020 00:22:43 +0000 (20:22 -0400)]
fstests: drop check.log and check.time into section specific results dir
Right now we only track check.log and check.time globally, it would
be nice to do it per-section as well. This makes it easier to parse
results from systems that run a bunch of different configurations at
once.
Yang Xu [Fri, 16 Oct 2020 09:31:23 +0000 (17:31 +0800)]
xfs/521: use _try_scratch_mount instead of _scratch_mount
Here will check the return code of mount option. So update it
to use _try_scratch_mount.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Sun, 11 Oct 2020 12:38:52 +0000 (13:38 +0100)]
fstests: add a filter for the new getcap output
Starting with version 2.41 of libcap, the output of the getcap program
changed and therefore some existing tests fail when the installed version
of libcap is >= 2.41 (the latest version available at the moment is 2.44).
The change was made by the following commit of libcap:
A more compact form for the text representation of capabilities.
While this does not change anything about the supported range of
equivalent text specifications for capabilities, as accepted by
cap_from_text(), this does alter the preferred output format of
cap_to_text() to be two characters shorter in most cases. That is,
what used to be summarized as:
"= cap_foo+..."
is now converted to the equivalent text:
"cap_foo=..."
which is also more intuitive.
So add a filter to change the old format to the new one, an helper that
calls getcap with that filter, make existing tests use the new helper and
update their golden output to match the new output format of getcap.
Darrick J. Wong [Thu, 8 Oct 2020 15:05:51 +0000 (08:05 -0700)]
xfs: test running growfs on the realtime volume
Make sure that we can run growfs to expand the realtime volume without
it blowing up. This is a regression test for the following patches:
xfs: Set xfs_buf type flag when growing summary/bitmap files
xfs: Set xfs_buf's b_ops member when zeroing bitmap/summary files
xfs: fix realtime bitmap/summary file truncation when growing rt volume
xfs: make xfs_growfs_rt update secondary superblocks
xfs: annotate grabbing the realtime bitmap/summary locks in growfs
Because the xfs maintainer realized that no, we have no tests for this
particular piece of functionality.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test checks "noatime" mount option effect, which makes it reasonable
to include the test into atime test group along with generic/003 and
generic/192 tests.
The test properly depends on _require_atime and for certain filesystems
the test is not run:
[not run] atime related mount options have no effect on cifs
Eric Sandeen [Thu, 8 Oct 2020 21:22:13 +0000 (16:22 -0500)]
generic: test reflinked file corruption after short COW
This test essentially creates an existing COW extent which
covers the first 1M, and then does another IO that overlaps it,
but extends beyond it. The bug was that we did not trim the
new IO to the end of the existing COW extent, and so the IO
extended past the COW blocks and corrupted the reflinked files(s).
The bug came and went upstream. It was introduced by:
78f0cc9d55cb "xfs: don't use delalloc extents for COW on files with extsize hints"
and (inadvertently) fixed as of: 36adcbace24e "xfs: fill out the srcmap in iomap_begin"
upstream, and in the 5.4 stable tree with: aee38af574a1 "xfs: trim IO to found COW extent limit"
[Eryu: discard outputs of xfs_io when setting [cow]extsize]
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Biggers [Thu, 1 Oct 2020 00:25:07 +0000 (17:25 -0700)]
f2fs: verify ciphertext of compressed+encrypted file
In Linux v5.6, f2fs added support for per-file compression. f2fs
compression can be used in combination with the existing f2fs encryption
support (a.k.a. fscrypt), in which case the compressed data is encrypted
rather than the uncompressed data.
We need to verify that the encryption is actually being done as expected
in this case. So add a test which verifies it.
For now this is a f2fs-specific test. It's possible that ext4 will
implement compression in the same way as f2fs (in which case this could
be made a generic test), but for now there are no plans for that.
This complements the existing ciphertext verification tests, e.g.
generic/548, which don't handle compression. Encryption+compression has
some unique considerations, so it requires its own test.
Eric Biggers [Thu, 1 Oct 2020 00:25:05 +0000 (17:25 -0700)]
fscrypt-crypt-util: add --block-number option
Currently fscrypt-crypt-util assumes that the number of the first block
encrypted/decrypted is 0. I.e., it replicates either contents
encryption from the start of a file, or encryption of a filename.
However, to easily test compression+encryption on f2fs, we need the
ability to specify a different starting block number.
Eric Biggers [Thu, 1 Oct 2020 00:25:04 +0000 (17:25 -0700)]
fscrypt-crypt-util: fix IV incrementing for --iv-ino-lblk-32
fscrypt-crypt-util treats the "block number" part of the IV as 64-bit
when incrementing it. That's wrong for --iv-ino-lblk-32 and
--iv-ino-lblk-64, as in those cases the block number should be 32-bit.
Fix this by using the correct length for the block number.
For --iv-ino-lblk-64 this doesn't actually matter, since in that case
the block number starts at 0 and never exceeds UINT32_MAX.
But for --iv-ino-lblk-32, the hashed inode number gets added to the
original block number to produce the IV block number, which can later
wrap around from UINT32_MAX to 0. As a result, this change fixes
generic/602, though since the wraparound case isn't specifically tested
currently, the chance of failure was extremely small.
Xiao Yang [Sat, 3 Oct 2020 03:37:35 +0000 (11:37 +0800)]
overlay/071: Don't compare inode numbers in lower overlay and nested overlay
1) If underlying filesystem is ext4, the lower overlay inodes do not
have the MSB set (e.g. file ino 8590721028 = 0x2000C0004) because
ext4 has a known inode number limit of 32bit (see ovl_can_decode_fh).
2) With nested xino feature, the nested overlay inodes have the MSB set
(e.g. file ino 9223372045445496836 = 0x80000002000C0004).
It is expected different inode numbers which casue the failure of
overlay/071, so fix this failure by removing the unneeded comparision.
Suggested-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
It appears that the goal of this case was to test balance and
replace concurrency. But these two operations aren't meant to run
concurrently and the replace failing errors are captured in the
seqres.full output. Which are expected errors. To avoid further
confusion, this patch adds comments. The reason to keep this
test case is at the Link.
Link: https://patchwork.kernel.org/patch/11806307/ Reported-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Wed, 23 Sep 2020 14:31:47 +0000 (15:31 +0100)]
btrfs: test fstrim after doing a device replace
Test that after replacing a device, if we run fstrim against the filesystem
we do not trim/discard allocated chunks in the new device. We verify that
allocated chunks in the new device were not trim/discarded by mounting the
new device only in degraded mode, as this is the easiest way to verify it.
This currently fails on btrfs (since kernel 5.2) and is fixed by a patch
that has the following subject:
"btrfs: fix filesystem corruption after a device replace"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Mon, 21 Sep 2020 13:15:32 +0000 (14:15 +0100)]
btrfs: test incremental send after swapping same file with two directories
Test an incremental send operation after doing a series of changes in a
tree such that one inode gets two hardlinks with names and locations
swapped with two other inodes that correspond to different directories,
and one of these directories is the parent of the other directory.
This currently fails on btrfs, the receive of the incremental send stream
fails. This is fixed by a patchset for btrfs which has two patches with the
following subjects:
"btrfs: send, orphanize first all conflicting inodes when processing references"
"btrfs: send, recompute reference path after orphanization of a directory"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Mon, 21 Sep 2020 13:15:31 +0000 (14:15 +0100)]
btrfs: test incremental send after a succession of rename and link operations
Test that an incremental send operation emits the correct path for link
and rename operation after swapping the names and locations of several
inodes in a way that creates a nasty dependency of rename and link
operations. Notably one file has its name and location swapped with a
directory for which it used to have a directory entry in it.
This test currently fails but a kernel patch for it exists and has the
following subject:
"btrfs: send, orphanize first all conflicting inodes when processing references"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Zorro Lang [Fri, 11 Sep 2020 07:15:54 +0000 (15:15 +0800)]
fsx: introduce fsx_rw to combine aio_rw with general read and write
The fsx contains different read and write operations, especially the
AIO and general IO read/write. The fsx chooses one kind of read/write
from AIO and general IO to run. To make the logic clear, use a common
fsx_rw() function to swith between these two kinds of read/write.
Signed-off-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Zorro Lang [Fri, 11 Sep 2020 07:15:52 +0000 (15:15 +0800)]
fsstress: reduce the number of events when io_setup
The original number(128) of aio events for io_setup too big. When try
to run lots of fsstress processes(e.g. -p 1000) always hit io_setup
EAGAIN error, due to the nr_events exceeds the limit of available
events. Due to each fsstress process only does once libaio read/write
operation each time. So reduce the aio events number to 1, to make more
fsstress processes can do AIO test.
Signed-off-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Fri, 18 Sep 2020 02:10:22 +0000 (19:10 -0700)]
common: drop HOSTOS
We effectively support only Linux these days, so drop most of the
special casing of HOSTOS. We'll retain the simple check just in case
someone tries to run this on a different operating system.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Eryu Guan <guaneryu@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:45:21 +0000 (18:45 -0700)]
generic/204: sync before scrub hits EIO
Let's see if we can prevent fs corruption warnings by flushing dirty
data to disk before the test ends.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:45:15 +0000 (18:45 -0700)]
xfs/141: run for longer with TIME_FACTOR
Allow the test runner to run the crash loop in this test for longer by
setting TIME_FACTOR. This has been useful for finding bugs in log
recovery.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Fri, 18 Sep 2020 02:08:33 +0000 (19:08 -0700)]
common/rc: teach _scratch_mkfs_sized to set a size on an xfs realtime volume
Generally speaking, tests that call _scratch_mkfs_sized are trying to
constrain a test's run time by formatting a filesystem that's smaller
than the device. The current helper does this for the scratch device,
but it doesn't do this for the xfs realtime volume.
If fstests has been configured to create files on the realtime device by
default ("-d rtinherit=1) then those tests that want to run with a small
volume size will instead be running with a huge realtime device. This
makes certain tests take forever to run, so apply the same sizing to the
rt volume if one exists.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:45:02 +0000 (18:45 -0700)]
xfs/449: fix xfs info report output if realtime device specified
Modify the mkfs.xfs output so that "realtime =/dev/XXX" becomes
"realtime =external" so that the output will match xfs_db, which doesn't
take a rt device argument and thus does not know.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:56 +0000 (18:44 -0700)]
xfs/424: disable external devices
This test uses an open-coded call to mkfs, so we need to disable the
external devices so that _scratch_xfs_db doesn't get confused. We also
disable the post-check fsck because it's run by the parent ./check
program, which won't know that we didn't use the external devices.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:43 +0000 (18:44 -0700)]
xfs: refactor _xfs_check calls to the scratch device
Use _scratch_xfs_check, not _xfs_check $SCRATCH_DEV.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:37 +0000 (18:44 -0700)]
xfs/098: adapt to external log devices
Teach this test to deal with external log devices correctly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:24 +0000 (18:44 -0700)]
common/xfs: extract minimum log size message from mkfs correctly
Modify the command that searches for the minimum log size message from
mkfs to handle external log devices correctly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:18 +0000 (18:44 -0700)]
generic/204: don't flood stdout with ENOSPC messages on an ENOSPC test
This test has been on and off my bad list for many years due to the fact
that it will spew potentially millions of "No space left on device"
errors if the file count calculations are wrong. The calculations
should be correct for the XFS data device, but they don't apply to other
filesystems.
Therefore, filter out the ENOSPC messages when the files are not going
to be created on the xfs data device (e.g. ext4, xfs realtime, etc.)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:12 +0000 (18:44 -0700)]
overlay/020: make sure the system supports the required namespaces
Don't run this test if the kernel doesn't support namespaces.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:44:05 +0000 (18:44 -0700)]
overlay/{069,071}: fix undefined variables
Change OVL_BASE_TEST_MNT -> OVL_BASE_TEST_DIR, since the former is not
actually defined anywhere.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:59 +0000 (18:43 -0700)]
xfs: add a _require_xfs_copy helper
Add a _require helper so that tests can ensure that they're running in
the correct environment for xfs_copy to work (no external devices).
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:53 +0000 (18:43 -0700)]
xfs/070: add scratch log device options to direct repair invocation
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:47 +0000 (18:43 -0700)]
xfs: replace open-coded calls to xfs_logprint with helpers
Use the test/scratch xfs_logprint helpers.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:40 +0000 (18:43 -0700)]
xfs/{111,137}: replace open-coded calls to repair with _scratch_xfs_repair
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:34 +0000 (18:43 -0700)]
xfs: wrap xfs_db calls to the test device
Create a _test_xfs_db analogue to _scratch_xfs_db so that we can
encapsulate whatever strange test fs options were fed to us by the test
runner.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:27 +0000 (18:43 -0700)]
xfs/{019, 031}: make sure we don't set rtinherit=1 on mkfs
mkfs.xfs does not support setting rtinherit on the root directory /and/
pre-populating the filesystem with protofiles, so don't run this test if
rtinherit is in the mkfs options.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:21 +0000 (18:43 -0700)]
xfs: skip tests that rely on allocation behaviors of the data device
A large number of xfs-specific tests rely on specific behaviors of the
data device allocator, such as fragmenting free space, carefully curated
inode and free space counts, or features like filestreams that only
exist on the data device.
These tests fail horribly if the test runner specified rtinherit=1 on
the mkfs command line, so skip them all.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:15 +0000 (18:43 -0700)]
generic/607: don't break on filesystems that don't support FSGETXATTR on dirs
This test requires that the filesystem support calling FSGETXATTR on
regular files and directories to make sure the FS_XFLAG_DAX flag works.
The _require_xfs_io_command tests a regular file but doesn't check
directories, so generic/607 should do that itself. Also fix some typos.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:08 +0000 (18:43 -0700)]
generic/60[01]: fix test failure when setting new grace limit
The setquota command can extend a quota grace period by a certain number
of seconds. The extension is provided as a number of seconds relative
to right now. However, if the system clock increments the seconds count
after this test assigns $now but before setquota gets called, the test
will fail because $get and $set will be off by that 1 second. Allow for
that.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong [Tue, 15 Sep 2020 01:43:00 +0000 (18:43 -0700)]
xfs/331: don't run this test if fallocate isn't supported
This test requires fallocate, so make sure that actually works before
running it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Xiao Yang [Mon, 14 Sep 2020 05:14:00 +0000 (13:14 +0800)]
common/rc: Add extra check for xfs_io -c "chattr" on XFS
On XFS, ioctl(FSSETXATTR)(called by xfs_io -c "chattr") maskes off unsupported
or invalid flags silently. For example,
1) With kernel v4.4 which doesn't support dax flag, try to set dax flag on a
file by the lastest xfs_io -c "chattr" command:
--------------------------------------------
0
----------------X testfile
--------------------------------------------
2) Realtime inheritance flag is only valid for a directory and try to set
realtime inheritance flag on a file:
--------------------------------------------
0
----------------X testfile
--------------------------------------------
In this case, we need to check these flags by extra ioctl(FSGETXATTR)(called
by xfs_io -c "lsattr").
Brian Foster [Tue, 1 Sep 2020 13:47:28 +0000 (09:47 -0400)]
generic/470: use thin volume for dmlogwrites target device
dmlogwrites support for XFS depends on discard zeroing support of
the intended target device. Update the test to use a thin volume and
allow it to run consistently and reliably on XFS.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Brian Foster [Tue, 1 Sep 2020 13:47:27 +0000 (09:47 -0400)]
generic/457: use thin volume for dmlogwrites target device
dmlogwrites support for XFS depends on discard zeroing support of
the intended target device. Update the test to use a thin volume and
allow it to run consistently and reliably on XFS.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Brian Foster [Tue, 1 Sep 2020 13:47:26 +0000 (09:47 -0400)]
generic/455: use thin volume for dmlogwrites target device
dmlogwrites support for XFS depends on discard zeroing support of
the intended target device. Update the test to use a thin volume and
allow it to run consistently and reliably on XFS.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Explicitly specify the xattr namespace required for tests.
This allows tests to be skipped correctly for filesystems
that don't support all xattr namespaces.
This changes all tests that require anything other than
the "user" xattr namespace. When called without arguments
as before, _require_attrs() still defaults to the "user"
namespace, so those tests do not need to be changed.
Signed-off-by: Frank van der Linden <fllinden@amazon.com> Reviewed-by: Eryu Guan <guaneryu@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
common/attr: make _require_attrs more fine-grained
Filesystems may not support all xattr types. But, _require_attr assumes
that being able to use "user" namespace xattrs means that all namespaces
("trusted", "system", etc) are supported. This breaks on NFS, that only
supports the "user" namespace, and a few cases in the "system" namespace.
Change _require_attrs to optionally take namespace arguments that specify
the namespaces to check for. The default behavior (no arguments) is still
to check for the "user" namespace only.
Signed-off-by: Frank van der Linden <fllinden@amazon.com> Reviewed-by: Eryu Guan <guaneryu@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana [Tue, 8 Sep 2020 10:32:02 +0000 (11:32 +0100)]
generic: add test for zero range over a file range with many small extents
Test a fallocate() zero range operation against a large file range for which
there are many small extents allocated. Verify the operation does not fail
and the respective range return zeroes on subsequent reads.
This test is motivated by a bug found on btrfs. The patch that fixes the
bug on btrfs has the following subject:
"btrfs: fix metadata reservation for fallocate that leads to transaction aborts"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This new test will apply different mount points and check if they
were applied by reading /proc/self/mounts. Almost all available
btrfs options are tested here, leaving only device=, which is tested
in btrfs/125 and space_cache, tested in btrfs/131.
This test does not apply any workload after the fs is mounted, just
checks is the option was set/unset correctly.
Kernel with the following patch should pass the test:
btrfs: reset compression level for lzo on remount
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The btrfs/154 testcase fails if the kernel patch "btrfs: handle
dynamically reappearing missing device" isn't applied, but this patch was
never merged into the upstream kernel.
Delete the test so we have one less testcase that will always fail.
Josef Bacik [Wed, 2 Sep 2020 17:10:36 +0000 (13:10 -0400)]
generic: test deadlock on O_DIRECT|O_DSYNC
We had a problem recently where btrfs would deadlock with
O_DIRECT|O_DSYNC because of an unexpected dependency on ->fsync in
iomap. This was only caught by chance with aiostress, because weirdly
we don't actually test this particular configuration anywhere in
xfstests. Fix this by adding a basic test that just does
O_DIRECT|O_DSYNC writes. With this test the box deadlocks right away
with Btrfs, which would have been helpful in finding this issue before
the patches were merged.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Nikolay Borisov [Mon, 17 Aug 2020 10:37:18 +0000 (13:37 +0300)]
btrfs/174: Adjust error message when setting compressed flag
Following kernel commit "btrfs: add missing check for nocow and
compression inode flags" btrfs refuses setting +c on +C files during
validation of the args. Account for this by adjusting the expected
error message.
Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Nikolay Borisov [Mon, 17 Aug 2020 10:37:17 +0000 (13:37 +0300)]
btrfs/173: Adjust compress file check
Following kernel commit "btrfs: add missing check for nocow and
compression inode flags" the enforcement of "can't set +c on a +C" file
has been moved to the ioctl code. Modify the test to account for this.
projects / xfstests-dev.git / log