Age | Commit message (Collapse) | Author | Files | Lines |
|
Got a new box running overnight fstests and noticed a couple of failures
because I forgot to enable loop device support. Fix these two tests to
have _require_loop so they don't fail if there's no loop device support.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Even kernel doesn't get ATTR_KILL_SGID mask and get ATTR_KILL_SUID mask,
we still can strip S_ISGID mode in setattr_prepare and setattr_copy.
We should check separate sgid stripping logic whether works well
on different filesystems.
Also fix comments error.
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Due to upstream linux has removed ALLOCSP/FREESP ioctls by commit:
4d1b97f9ce7c0 ("xfs: kill the XFS_IOC_{ALLOC,FREE}SP* ioctls"), so
let's remove ALLOCSP/FREESP testing from fsstress, to avoid more
mismatch problems.
Due to g/070 specified "-f allocsp" and "-f freesp=0", so remove
these two lines too.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Compression and nodatacow are mutually exclusive. Besides ioctl, there
is another way to setting compression via xattrs, and shouldn't produce
invalid combinations.
Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test was designed to validate the quota warning limit, which in
theory was supposed to migrate from a soft quota to hard enforcement
after a certain number of warnings. However, the xfs kernel commit
which incremented the warning counter was reverted; see:
xfs: revert "xfs: actually bump warning counts when we send warnings"
in the kernel tree for an explanation of why. Due to that revert,
which removed this functionality, remove this test.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
These two tests are checking whether a non-privileged user causing a
block allocation while expanding a directory block when over quota
will fail with an EDQUOT error. There are three reasons why this can
fail.
* Aa test bug, where if the file system is using cluster allocation
(for example, ext4 bigalloc) the test doesn't add enough directory
entries to actually force directory grwoth.
* A file system bug, where the file system allocates blocks but for
some reason isn't charging the space quota correctly (which
currently seems to be the case in ext4 with fscrypt).
* A file system bug, where the file system is correctly charging the
space quota to the unprivileged user, but isn't failing the system
call with EDQUOT.
By adding some additional debugging information about whether
directory has grown or not (in addition to the existing repquota
output) to the the $seqres.full, it makes easier for the file system
developer to disambiguate between these possibilities. It's cheap to
do this, and it could save developer time when trying to root cause
the failure.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
After coreutils rebasing to 9.1, chown(1) behavior changes:
"
chown and chroot now warn about usages like "chown root.root f",
which have the nonstandard and long-obsolete "." separator that
causes problems on platforms where user names contain ".".
Applications should use ":" instead of ".".
"
https://lwn.net/Articles/891574/
With this behavior change, old format of ownership string will cause
warning like this:
"
+chown: warning: '.' should be ':': '1000.1000'
+.chown: warning: '.' should be ':': '1100.1100'
+.chown: warning: '.' should be ':': '1200.1200'
+.chown: warning: '.' should be ':': '1300.1300'
+.chown: warning: '.' should be ':': '1400.1400'
"
The new format works fine with old versions of coreutils.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
Reviewed-by: Zorro Lang <zlang@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a regression test for commit 705191b03d50 ("fs: fix acl translation").
This tests whether setting POSIX ACLs on a tmpfs mounted in a
non-initial user and mount namespace works as expected.
Note, once again the idmapped mount testsuite is grossly misnamed at
this point. It has morphed into a full-blown generic vfs feature
testsuite.
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Zorro Lang <zlang@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Zorro Lang <zlang@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
fallocate changes file contents, so make sure that we drop privileges
and file capabilities after each fallocate operation.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This is a regression test to make sure that nonzero error returns from
a filesystem's ->sync_fs implementation are actually passed back to
userspace when the call stack involves syncfs(2).
[zlang@ add '_supported_fs xfs' in case]
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Currently tests in xfstests-dev can be executed against CephFS only by
mounting CephFS using kernel driver. Attempting to run tests against
CephFS using FUSE doesn't work because xfstests-dev would remount CephFS
using kernel. This patch adds the ability for xfstest-dev code to mount
CephFS using FUSE.
[Zorro add missed ";;" in common/rc]
Fixes: https://tracker.ceph.com/issues/55354
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Fix incorrect usage of unset -- one passes the name of the variable, not
the *value* contained within it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
A recent change to xfs/019 exposed a long-standing bug in mkfs where
it would always set the gid of a new child created in a setgid directory
to match the gid parent directory instead of what's in the protofile.
Ignoring the user's directions is not the correct behavior, so update
this test to reflect that. Also don't erase the $seqres.full file,
because that makes forensic analysis pointlessly difficult.
Cc: Catherine Hoang <catherine.hoang@oracle.com>
Fixes: 7834a740 ("xfs/019: extend protofile test")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This tests a longstanding bug where xfsdumps are not properly
created when an inode is present on the filesytsem which has
a lower number than the root inode.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
|
|
The _wipe_fs function in common/dump is a historical remnant of
xfstests, it's easy to cause confusion now. Now xfstests tend to
call `require_scratch && scratch_mkfs && scratch_mount` in each case
itself, we don't need to use a function to do that specially, so
remove _wipe_fs entirely.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
|
|
Some tests in idmapped_mounts fail without CONFIG_USER_NS because they
have implicit dependence on user namespaces and these tests are run
despite idmapped mount support not being detected. Detect whether at
least user namespaces are supported and skip tests needing them when
they are not.
Signed-off-by: Jan Kara <jack@suse.cz>
Tested-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Currently idmapped_mounts tests fail for kernels without CONFIG_USER_NS
because some tests are run despite missing support for idmapped mounts
and they implicitely require user namespace support. Prepare
idmapped_mounts to support more features a test may require to reliably
run.
Signed-off-by: Jan Kara <jack@suse.cz>
Tested-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a regression test to make sure that unprivileged userspace renaming
within a directory fails with EDQUOT when the directory quota limits have
been exceeded.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add a regression test to make sure that unprivileged userspace linking
into a directory fails with EDQUOT when the directory quota limits have
been exceeded.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
If you ctrl-c generic/019, it leaves fsstress processes running.
Kill them in the cleanup function so that they don't have to be
manually killed after interrupting the test.
While touching the _cleanup() function, make it do everything that
the generic _cleanup function it overrides does and fix the
indenting.
[Eryu: unset fs_pid and fio_pid after wait]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
mkfs will soon refuse to format a log smaller than 64MB, so update this
test to reflect the new log sizing calculations.
[Eryu: add xfs/216.cfg and use _link_out_file_name to choose .out file]
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add a new regression test for a stack corruption problem uncovered in
the mkfs config file parsing code.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Now that xfs_scrub can report whether or not it was built with the
Unicode name checker, rewrite _check_xfs_scrub_does_unicode to take
advantage of that. This supersedes the old method of trying to observe
dynamic library linkages and grepping the binary, neither of which
worked very well.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ceph kernel client now has a facility to check stats for certain
operations. One of these operations is the 'copyfrom', the
operation that is used to offload to the OSDs the copy of objects
from, for example, the copy_file_range() syscall.
This patch changes ceph/001 to add an extra check to verify that the
copies performed by the test are _really_ remote copies and not
simple read+write operations.
Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
When run on ext4 with sufficiently fast x86_64 hardware, generic/130
sometimes fails because xfs_io can report rate values as -nan:
0.000000 bytes, 0 ops; 0.0000 sec (-nan bytes/sec and -nan ops/sec)
_filter_xfs_io matches the strings 'inf' or 'nan', but not '-nan'. In
that case it fails to convert the actual output to a normalized form
matching generic/130's golden output. Extend the regular expression
used to match xfs_io's output to fix this.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Make the encryption tests create and use a named keyring "xfstests" in
the session keyring that the tests happen to be running under, rather
than replace the session keyring using 'keyctl new_session'.
Unfortunately, the latter doesn't work when the session keyring is owned
by a non-root user, which (depending on the Linux distro) can happen if
xfstests is run in a sudo "session" rather than in a real root session.
This isn't a great solution, as the lifetime of the keyring will no
longer be tied to the tests as it should be, but it should work. The
alternative would be the weird hack of making the 'check' script
re-execute itself using something like 'keyctl session - $0 $@'.
Reported-by: Ritesh Harjani <ritesh.list@gmail.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
|
|
open_by_handle_at(2) is not supported by virtio-fs.
Reference:
https://gitlab.com/virtio-fs/qemu/-/issues/10
Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Currently, this test relies on the XFS_IOC_FSCOUNTS ioctl to return
accurate free space information. It doesn't. Convert it to use statfs,
which uses the accurate versions of the percpu counters. Obviously,
this only becomes a problem when we convert the free rtx count to use
(sloppier) percpu counters instead of the (more precise and previously
buggy) ondisk superblock counts.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add this regression test to the auto group now that it's been quite a
while since the fix patches went upstream.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The current attr -g "$max_attrval_name" output filter is broken if
$max_attrval_size isn't 16-byte aligned, due to od's duplicate
suppression behaviour.
Fix it by having od only dump one byte per line.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
As found by Dave Chinner, fff4359d ("020: make this xattr test generic")
unintentionally changed the long attribute value length from 100K to 64
*bytes* for XFS, UDF and Btrfs.
Update XFS and UDF to use a 64K $max_attrval_size value. For Btrfs, use
the nodesize, xattr length and tree entry overhead sizes to calculate
the maximum.
NFS doesn't provide a way to find out the $max_attrval_size for the
underlying filesystem on the server, so just use a rough 1K limit.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In preparation for taking into account the attr name length when
calculating $MAX_ATTRVAL_SIZE, put the current logic in a
_attr_get_max() helper function and set local $max_attrval_size /
$max_attrs variables instead of using export.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
No functional change. MAX_ATTRS and MAX_ATTRVAL_SIZE are only used
within generic/020, so move the logic for determining these values
over there.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
After the recent commit 4a7b35d7a76cd9 ("common: allow to run all tests
on idmapped mounts"), some test that use _try_scratch_mount started to
fail. For example:
$ ./check btrfs/131 btrfs/220
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian9 5.17.0-rc8-btrfs-next-114 (...)
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/131 2s ... - output mismatch (see .../results//btrfs/131.out.bad)
--- tests/btrfs/131.out 2020-06-10 19:29:03.818519162 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/131.out.bad (...)
@@ -6,8 +6,6 @@
Disabling free space cache and enabling free space tree
free space tree is enabled
Trying to mount without free space tree
-mount failed
-mount failed
Mounting existing free space tree
free space tree is enabled
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/131.out ...
btrfs/220 7s ... - output mismatch (see .../results//btrfs/220.out.bad)
--- tests/btrfs/220.out 2020-10-16 23:13:46.802162554 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/220.out.bad (...)
@@ -1,2 +1,32 @@
QA output created by 220
+Option fragment=invalid should fail to mount
+umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted.
+Option nologreplay should fail to mount
+umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted.
+Option norecovery should fail to mount
+umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted.
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/220.out ...
Ran: btrfs/131 btrfs/220
Failures: btrfs/131 btrfs/220
Failed 2 of 2 tests
The reason is that if _try_scratch_mount() fails to mount the filesystem,
we don't return the failure, instead we call _idmapped_mount(), which
can succeed and make _try_scratch_mount() return 0 (success). The same
happens for _test_mount(), however a quick search revealed no tests
currently relying on the return value of _test_mount().
So fix that by making _try_scratch_mount() return immediately if it gets
a mount failure. Also do the same for _test_mount().
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test for the Dirty Pipe vulnerability (CVE-2022-0847) caused by an
uninitialized "pipe_buffer.flags" variable. The bug cause a file
can be overwritten even if a user/process is not permitted to write
it. It's fixed by 9d2231c5d74e ("lib/iov_iter: initialize "flags" in
new pipe_buffer").
Cc: Max Kellermann <max.kellermann@ionos.com>
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The "od" is one of the most fundamental commands in GNU/Linux and
most Unix-like systems. So we nearly always can count on it, don't
need to check if it's installed.
The "hexdump" isn't such fundamental as "od", some systems don't
install it by default. And as "od" nearly can replace all functions
of "hexdump", so let's use an unified command "od" to do the hexdump
job in fstests cases.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In addition to the generic and filesystem-specific idmapped mount
testsuites that already exist upstream today add simple
infrastructure so any test can be run on idmapped mounts simply by
setting IDMAPPED_MOUNTS=true in the config file or section. The main
user for now will be overlay to verify it works correctly on
idmapped mounts.
Note that the infrastructure is completely generic so every
filesystem that supports idmapped mounts can simply run all of their
tests idmapped. But note that not all ways to create a mount have
been converted yet. That includes e.g. _dmthin_mount and direct
calls to _mount in various tests.
In addition, there will be corner-cases. For example, xfs doesn't
allow bulkstat on idmapped mounts because it is a filesystem wide
operation, i.e. you can retrieve information for any inode in the
filesystem so the operation cannot be scoped reasonably under a
single mount. So xfstests testing bulkstat will fail as it's
blocked. Similar for some btrfs ioctl()s.
While we could of course restrict this testmode to -overlay for
which we know things work correctly we should not do this. It would
mean that people won't start using it and so we won't see issues
unless someone sits down and goes through more than 1000 tests and
figures out for each individual one whether it needs to be skipped
or not.
So instead allow this mode but for all filesystems so people can
start running and reporting failures and we can fix them up or block
them as we detect them.
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <fstests@vger.kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
fscrypt keys have used the $FSTYP as prefix. However this format is being
deprecated and newer kernels are expected to use the generic 'fscrypt:'
prefix instead. This patch adds support for this new prefix, and only
uses $FSTYP on filesystems that didn't initially supported it, i.e. ext4 and
f2fs. This will allow old kernels to be tested.
Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This line doesn't result in a changed count value. The tests don't
appear to rely on a decremented value, so remove the line.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Due to XFS_IOC_ALLOCSP is nearly retired from linux xfs, and the
ALLOCSP testing in fsx easily trigger errors. So compare with
disable it by default, I'd like to remove it entirely. So this patch
revert two patches:
cd99a499 ("fsx: disable allocsp_calls if -F is specified")
a32fb1bb ("fsx: add support for XFS_IOC_ALLOCSP")
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test will break when zone capacity != zone size because the
calculation of the size to be filled is done using zone_size instead
of the actual capacity available per zone. Fix it by using zone
capacity.
As a zoned device can have variable capacity, use the btrfs utility
to get the zone capacity from the first data block group that the
test will be performed on.
The support to extract zone capacity was added to blkzone only from
version 2.37. So zcap will be used only when the blkzone version is
greater or equal to 2.37.
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Since btrfs has subpage support since v5.15, there is no need to
require such hard requirement on 4K page size.
We only need to check if the current system support 4K as
sectorsize.
Now the test case can pass on aarch64 with 64K page size.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
unsupported profile
[BUG]
Sometimes the tester wants to use $BTRFS_PROFILE_CONFIGS to limit the
tests to certain profiles.
This is especially useful for btrfs subpage tests, as we don't yet
support RAID56 for it yet.
But unfortunately, if we specify $BTRFS_PROFILE_CONFIGS with the
following content:
export BTRFS_PROFILE_CONFIGS="single:single dup:single raid0:raid0 \
raid1:raid1 raid10:raid10"
A lot of tests will not run, like:
btrfs/064 30s ... [not run] Profile dup not supported for replace
btrfs/065 26s ... [not run] Profile dup not supported for replace
btrfs/066 27s ... 14s
btrfs/069 25s ... [not run] Profile dup not supported for replace
btrfs/070 59s ... [not run] Profile dup not supported for replace
btrfs/071 25s ... [not run] Profile dup not supported for replace
[CAUSE]
Those test cases uses _btrfs_get_profile_configs() to grab the profiles
which support given workload (like replace/repace-missing).
But _btrfs_get_profile_configs() will behave different based on whether
BTRFS_PROFILE_CONFIGS is defined.
If not defined, it goes with default profiles, and just skip those
unsupported.
This is what we want.
But if the environment variable is defined, it will not run if there is
any unsupported profile in it.
[FIX]
Unify the behaivor by always skip the unsupported profiles, no matter if
$BTRFS_PROFILE_CONFIGS is defined or not.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test creates an xfs filesystem and verifies that the filesystem
matches what is specified by the protofile.
This patch extends the current test to check that a protofile can
specify setgid mode on directories. Also, check that the created
symlink isn’t broken.
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
We now allow cross vfsmount reflinks, change this test to make sure
we pass the cross-vfsmount reflink.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
We allow for cross-vfsmount dedupes now, change this test to
validate dedupe works properly cross-vfsmount.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
We now allow cross-vfsmount reflinks so change the test to validate
that cross-vfsmount reflinks work.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Signed-off-by: Boyang Xue <bxue@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test fail on f2fs:
xattr names and values after second fsync log replay:
# file: SCRATCH_MNT/foobar
+user.attr1="val1"
user.attr3="val3"
attr1 is still there after log replay. f2fs doesn't support fs-op level
transaction functionality. so it have no way to persist all metadata
updates in one transaction. We can use "fastboot" mountoption for this
case, so during last fsync on qwerty, f2fs can trigger a checkpoint
which will persist all metadata updates before fsync().
Suggested-by: Chao Yu <chao@kernel.org>
Signed-off-by: Sun Ke <sunke32@huawei.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Since commit 2461e8901c ("generic/631: Add a check for extended
attributes"), check of user.* extended attributes was added to avoid
running this tests for filesystems that are not supported.
But it still fails on NFSv4.2 when mount overlayfs with the
following error.
/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: upper fs does not support xattr, falling back to index=off and metacopy=off.
As per the linux patch series(https://lwn.net/Articles/799185/ ), the
support of user extended attributes were added to NFSv4.2. So this
case passed the check of extended attributes by _require_attrs.
As per the overlayfs documentation -
"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."
So we can replace user.* extended attributes check with trusted.* to
filter NFS filesystem.
Signed-off-by: Dai Shili <daisl.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Reading sysfs to get physical and logical block fails,
if SCRATCH_DEV is partitioned device.
Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
Reported-by: Darrick J. Wong <djwong@kernel.org>
Reported-by: Wang Yugui <wangyugui@e16-tech.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test that if we call fallocate against a file range that has a mix
of holes and written extents, the fallocate succeeds if the
filesystem has enough free space to allocate extents for the holes.
This test currently fails on btrfs and is fixed by a patch that has the
following subject:
"btrfs: only reserve the needed data space amount during fallocate"
The test also fails on xfs, and after some discussion with Darrick,
it seems it's due to technical reasons that would require a
significant effort to xfs's implementation, and at the moment there
isn't enough motivation to do such change. The relevent thread is at:
https://lore.kernel.org/linux-btrfs/20220315164011.GF8241@magnolia/
Therefore the test is intentionally skipped on xfs only. Ext4 and
f2fs pass this test.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
As part of all the ciphertext verification tests, verify that the
filesystem correctly computed the key identifier from the key the test
generated. This uses fscrypt-crypt-util to compute the key identifier.
Previously this was only being tested indirectly, via the tests that
happen to use the hardcoded $TEST_RAW_KEY and $TEST_KEY_IDENTIFIER.
The new check provides better coverage.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
To help with debugging, log some additional information to $seqres.full.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add an option to fscrypt-crypt-util to make it compute the key
identifier for the given key. This will allow testing the correctness
of the filesystem's key identifier computation.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Split get_key_and_iv() into two distinct parts: (1) deriving the key and
(2) generating the IV. Also, check for the presence of needed options
just before they are used rather than doing it all up-front.
These changes should make this code much easier to understand.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Make fscrypt-crypt-util use an option --direct-key to specify the use of
the DIRECT_KEY method for key derivation and IV generation. Previously,
this method was implicitly detected via --mode-num being given without
either --iv-ino-lblk-64 or --iv-ino-lblk-32, or --kdf=none being given
in combination with --file-nonce.
The benefit of this change is that it makes the various options to
fscrypt-crypt-util behave more consistently. --direct-key,
--iv-ino-lblk-64, and --iv-ino-lblk-32 now all work similarly (they
select a key derivation and IV generation method); likewise, --mode-num,
--file-nonce, --inode-number, and --fs-uuid now all work similarly (they
provide information that key derivation and IV generation may need).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
These tests check that the filestreams allocator never shares an AG
across multiple streams when there's plenty of space in the filesystem.
Recent increases in metadata overhead for newer features (e.g. bigger
logs due to reflink) can throw this off, so add another AG to the
formatted filesystem to encourage it to avoid the AG with the log.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test checks that filesystems with sparse inode support can continue
to allocate inodes when free space gets fragmented. Inodes only exist
on the data device, so we need to ensure that realtime is not enabled on
the filesystem so that the rt metadata doesn't mess with the inode usage
percentage and cause a test failure.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Filipe Manana pointed out[1] that the setgid dropping behavior encoded
in this generic test is based on some outdated XFS code, and not based
on what the VFS inode attribute change functions actually do. Now that
we're working on fixing that, we should update the golden output to
reflect what all filesystems are supposed to be doing.
[1] https://lore.kernel.org/linux-xfs/CAL3q7H47iNQ=Wmk83WcGB-KBJVOEtR9+qGczzCeXJ9Y2KCV25Q@mail.gmail.com/
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Every now and then, this test fails with this golden output:
--- xfs/420.out
+++ xfs/420.out.bad
@@ -29,7 +29,7 @@
Whence Result
DATA 0
HOLE 131072
-DATA 196608
+DATA 192512
HOLE 262144
Compare files
c2803804acc9936eef8aab42c119bfac SCRATCH_MNT/test-420/file1
Curiously, the file checksums always match, and it's not *forbidden* for
the page cache to have a page backing an unwritten extent that hasn't
been written.
The condition that this test cares about is that block 3 (192k-256k) are
reported by SEEK_DATA as data even if the data fork has a hole and the
COW fork has an unwritten extent. Matthew Wilcox thinks this is a side
effect of readahead.
To fix this occasional false failure, call SEEK_DATA and SEEK_HOLE only
on the offsets that we care about.
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Fix some problems with undefined variables in the scrub control code.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Once in a /very/ long while this test fails because _mkfs_dev can't find
the LVM thinp volume after it's been created. Since the "solution" du
jour seems to be to sprinkle udevadm settle calls everywhere, do that
here in the hopes that will fix it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test doing a read, with io_uring, over a file range that includes
multiple extents. The read operation triggers page faults when
accessing all pages of the read buffer except for the pages
corresponding to the first extent. We want to check that the
operation results in reading all the extents and that it returns the
correct data.
This is motivated by an issue found with MariaDB when using io_uring
and running on btrfs. There's a patch for btrfs to address the issue
ca93e44bfb5f ("btrfs: fallback to blocking mode when doing async dio
over multiple extents")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
commit 25195eb ("xfsdump: handle bind mount target") introduced
a bug of xfsdump which doesn't store the files to the dump file
correctly when the root inode number is changed.
The commit 25195eb is reverted, and commit 0717c1c ("xfsdump: intercept
bind mount targets") which is in xfsdump v3.1.10 fixes the bug to reject
the filesystem if it's bind-mounted.
Test that xfsdump can reject the bind-mounted filesystem.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Kernel currently doesn't support resize of EXT4 mounted with
sparse_super2 option enabled. Earlier, it used to leave the resize
incomplete and the fs would be left in an inconsistent state,
however commit b1489186cc83[1] fixed this to avoid the fs corruption
by clearly returning -EOPNOTSUPP.
Test to ensure that kernel handles resizing with sparse_super2
correctly. Run resize for multiple iterations because this sometimes
leads to kernel crash due to fs corruption, which we want to detect.
Related commit in mainline:
[1] commit b1489186cc8391e0c1e342f9fbc3eedf6b944c61
ext4: add check to prevent attempting to resize an fs with sparse_super2
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The current implementation of ext4_resize returned 1 whenever
there was an error. Modify this to return the correct error code.
This is important for tests that rely on correct error reporting, by
the kernel, for ext4 resize functionality.
Additionaly, perform some code cleanup.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The commands for package managers for both Ubuntu and RHEL weren't
up-to-date. A few packages doesn't exist anymore or missing from the
latest repositories (e.g. liburing-devel, btrfs-progs-devel).
Ubuntu's list missed a few packages listed in RHEL's list. There are
a few repeating steps. The indent of avaliable environment variables
is not clear.
This patch:
- Update package dependencies for Ubuntu/Debian/RHEL/CentOS/Fedora
- Unify list of packages between Ubuntu/Debian and RHEL/CentOS/Fedora
- Add list of tool packages for other FS
- Add links to tools not in the standard repository for RHEL/CentOS
- Drop xfsprogs-qa-devel reference for old systems
- Replace note about EPEL with installation step with link to Fedora
manual
- Add configuration examples in 'Setup Environment'
- Small clarification details, such as size of the partition and
KCONFIG_PATH description
- Removal of repeating steps (install administrative tools,
partitions content)
- Restructuring and formatting of "BUILDING THE FSQA SUITE" section
- Drop IRIXDEV references in variable set up
- Variables in 'Additional setup' divided into groups
- Move fsqa user/group creation and udf_test to 'Setup Environment'
section
Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
There is a report that btrfs autodefrag is defragging extents which
only have one single sector.
Such defragging will not reduce the number of extents, but only
waste IO.
The fix for it is titled:
btrfs: avoid defragging extents whose next extents are not targets
Here we add a test case, which will create an inode with the
following layout:
0 16K 20K 64K
|<-- Extent A -->|<-B->|<----- Extent C --->|
|Gen 7 |Gen 9|Gen 7 |
And we trigger autodefrag with newer_than = 8, which means it will
only defrag extents newer than or equal to generation 8.
Currently only Extent B meets the condition, but it can not be
merged with Extent A nor Extent C, as they don't meet the generation
requirement.
Unpatched kernel will defrag only Extent B, resulting no change in
fragmentation, while costs extra IO.
Patched kernel will not defrag anything.
Although this is still not the ideal case, as we can defrag the
whole 64K range, but that's not what autodefrag can do with its
generation limitation.
And such "perfect" defrag can cause way more IO than some users can
stand.
At least we should not only defrag extent B.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
When the helper function _scratch_mkfs_sized is called with small
filesystem size and FSTYP=btrfs, it calls mkfs.btrfs with --mixed option
to enable mixed mode. However, mkfs.btrfs with --mixed option fails for
zoned block devices since btrfs does not support mixed mode together
with zoned mode. To avoid this failure, do not set --mixed option when
the scratch device is a zoned block device.
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test case btrfs/261, part from its comments, doesn't really exercise
any behaviour that is btrfs specific, so, as Dave Chinner pointed out, it
can be moved into the generic group.
This change moves that test into the generic group and slightly adjust the
comments to make it clear which parts are btrfs specific.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test enable/disable quota and create/destroy qgroup repeatedly in
parallel and confirm it does not cause kernel hang. It only happens
in kernel staring with kernel 5.17-rc3. This is a regression test
for the problem reported to linux-btrfs list [1].
The hang was recreated using the test case and fixed by kernel patch
titled
btrfs: qgroup: fix deadlock between rescan worker and remove qgroup
[1] https://lore.kernel.org/linux-btrfs/20220228014340.21309-1-realwakka@gmail.com/
Signed-off-by: Sidong Yang <realwakka@gmail.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
scsi_debug device used for test, is created with assumption of 512
bytes logical and physical block size.
This causes error in lvcreate step, when SCRATCH_DEV device lba is
not 512 bytes. This can be solved by reading block size from sysfs
of device. If sysfs is missing fallback to 512 bytes as default.
Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add test checking functionality of seekdir. We check whether seekdir
gets us back to the directory entry it should and also whether
seeking to random positions does not crash the filesystem.
Unlike test generic/310 which also tests seeking, this test checks both
glibc readdir() function as well as getdents64() syscall directly. This
is because glibc readdir() implementation does a lot of caching and
processing internally thus hiding kernel from some possible problems.
Also test wider range of random offsets to have better chance of
hitting out of bound accesses or other bugs.
This is a regression test for a48fc69fe658 ("udf: Fix crash after
seekdir")
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add the capability to capture btrfs metadumps when filesystem checks
fail, so that they can be used for further debugging. This is useful
for tests that _require_test and/or _require_scratch for which
filesystem checkers will run after a test completes and may
occasionally pick up inconsistencies.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test that after a full fsync of a file with preallocated extents
beyond the file's size, if a power failure happens, the preallocated
extents still exist after we mount the filesystem.
This test currently fails and there is a patch for btrfs that fixes
this issue and has the following subject:
"btrfs: fix lost prealloc extents beyond eof after full fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Most of the code in the function _filter_mkfs is xfs unique. This is
misleading that the function would be dedicated for xfs. Clean up the
function by factoring out xfs unique part to _xfs_filter_mkfs in
common/xfs. While at the same time, fix indent in _xfs_filter_mkfs to be
consistent with other functions in common/xfs.
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test cases xfs/015 calls _scratch_mkfs before _scratch_mkfs_sized,
and does not check return code of _scratch_mkfs_sized. Even if
_scratch_mkfs_sized failed, _scratch_mount after it cannot detect the
sized mkfs failure because _scratch_mkfs already created a file system
on the device. This results in unexpected test condition.
To avoid the unexpected test condition, check return code of
_scratch_mkfs_sized.
Suggested-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test cases ext4/021 calls _scratch_mkfs before _scratch_mkfs_sized,
and does not check return code of _scratch_mkfs_sized. Even if
_scratch_mkfs_sized failed, _scratch_mount after it cannot detect the
sized mkfs failure because _scratch_mkfs already created a file system
on the device. This results in unexpected test condition.
To avoid the unexpected test condition, check return code of
_scratch_mkfs_sized.
Suggested-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test cases generic/{171,172,173,174} call _scratch_mkfs before
_scratch_mkfs_sized, and they do not check return code of
_scratch_mkfs_sized. Even if _scratch_mkfs_sized failed, _scratch_mount
after it cannot detect the sized mkfs failure because _scratch_mkfs
already created a file system on the device. This results in unexpected
test condition of the test cases.
To avoid the unexpected test condition, check return code of
_scratch_mkfs_sized in the test cases.
Suggested-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test case generic/204 calls _scratch_mkfs to get data block size and
i-node size of the filesystem and obtained data block size is passed to
the following _scratch_mfks_sized call as an option. However, the
_scratch_mkfs call is unnecessary since the sizes can be obtained by
_scratch_mkfs_sized call without the data block size option.
Also the _scratch_mkfs call is harmful when the _scratch_mkfs succeeds
and the _scratch_mkfs_sized fails. In this case, the _scratch_mkfs
leaves valid working filesystem on scratch device then following mount
and IO operations can not detect the failure of _scratch_mkfs_sized.
This results in the test case run with unexpected test condition.
Hence, remove the _scratch_mkfs call and the data block size option for
_scratch_mkfs_sized call.
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Use $AWK_PROG instead of awk in case the default awk
program is not called awk.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Adam Manzanares <a.manzanares@samsung.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Use $AWK_PROG instead of just awk in case the preferred awk
program is different.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Adam Manzanares <a.manzanares@samsung.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Using $(findmnt -n -o UUID mount-directory) only works on
util-linux v2.38, not on 2.37. Even debian-testing has util-linux
v2.37, so use a mechanism which has worked for longer to fetch the
UUID.
Without this the test fails on permission failure on accessing
the file /sys/fs/btrfs/"$uuid"/bg_reclaim_threshold as $uuid is
empty. So while at it, add a check to ensure the UUID is never
empty.
Use $AWK_PROG in case the preferred awk program is not the
preferred awk program.
Cc: Karel Zak <kzak@redhat.com>
Cc: Pankaj Raghav <p.raghav@samsung.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Tested-by: Adam Manzanares <a.manzanares@samsung.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
When patient module removal support is detected on kmod
(note that this is not yet even merged onto kmod yet but
work in progress) the arguments required for it are not being
set yet. This was a typo, fix this.
This issue was spotted using shellcheck from blktests when adding
patient module removal support there. I'll post a patch next to
let folks evaluate if we should embrace shellcheck on fstests as
well.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
f2fs has set inline_xattr as a default option, and introduced a new
option named 'noinline_xattr' for disabling default inline_xattr
option. So in _acl_get_max we need to check 'noinline_xattr' string
in fs option, otherwise we may select the wrong max acl number since
we always found the string 'inline_xattr' in fs option.
Additionally, f2fs has changed disk layout of xattr block a bit, so
will contain one more entry in both inline and noinline xattr inode,
this patch will modify the max acl number to adjust it.
Suggested-by: Chao Yu <chao@kernel.org>
Signed-off-by: Sun Ke <sunke32@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In OpenSSL 3.0, MD_Init/Update/Final() interfaces are marked
deprecated, and we have to go EVP_DigestInit/Update/Final() instead.
Personally I'm not a fan of this, especially the new EVP_MD_CTX
structure can no longer be stack allocated, thus we have to
dynamically allocate and free EVP_MD_CTX in sum_init() and sum_free().
Hopes this is proper way to go and would solve the problem until
OpenSSL chooses to change their interface again.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Despite the regular file defragging, "btrfs filesystem defragment"
provides an option, -c, to convert all data extents (except holes
and preallocated ranges) to a new compression algorithm.
The special behavior here is, unlike regular defrag which is not
going to touch extents which are adjacent to preallocated/hole
ranges, with -c, all non-hole/non-preallocated extents should be
defragged and converted to the new compression algorithm.
This test case will ensure the old behavior is properly kept.
Currently both old kernels (v5.15 and older) and newer kernel with
refactored defrag (v5.16 and newer) can pass the tests.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
There is a long existing bug in btrfs defrag code that it will
always try to defrag compressed extents, even they are already at
max capacity.
This will not reduce the number of extents, but only waste IO/CPU.
The kernel fix is titled:
btrfs: defrag: don't defrag extents which is already at its max capacity
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In v5.11~v5.15 kernels, there is a regression in autodefrag that if
a cluster (up to 256K in size) has even a single hole, the whole
cluster will be rejected.
This will greatly reduce the efficiency of autodefrag.
The behavior is fixed in v5.16 by a full rework, although the rework
itself has other problems, it at least solves the problem.
Here we add a test case to reproduce the case, where we have a 128K
cluster, the first half is fragmented extents which can be
defragged. The second half is hole.
Make sure autodefrag can defrag the 64K part.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Recent v5.16 has some regression around btrfs autodefrag mount
option, and the extra scrutiny around defrag code exposes some
questionable behavior from the old code.
One behavior is to defrag extents along with the next preallocated
extent.
This behavior will cause extra IO and convert all the preallocated
extent to regular zero filled extents, rendering the preallocated
extent useless.
The kernel fix is titled:
btrfs: defrag: don't try to merge regular extents with preallocated extents
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
As the fsx.c source code says:
int fallocate_calls = 1; /* -F flag disables */
int allocsp_calls = 1; /* -F flag disables */
The allocsp_calls and fallocate_calls should be disabled, if the -F
option is specified. But current fsx forgets to disable allocsp_calls
as is documented.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Set maximum label length for ext4 in _label_get_max() to be able to test
online file system label set/get ioctls.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Because they use metadump and I want to test metadump more easily.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
There exists versions of modprobe out there which are so old that
modprobe --help isn't a thing. They're certainly not going to support
modprobe --remove-patiently, so test to make sure modprobe --help
works to avoid causing all tests to fail due to the error message
to stderr showing up in $seq.out.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fixes: 405c21d40aa1 ("common/module: add patient module rmmod support")
Reported-by: Leah Rumancik <leah.rumancik@gmail.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Deprecating this, so turn off the tests that require it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Make sure that we drop the setuid and setgid bits any time reflink or
dedupe change the file contents.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Make the requirement for daemon:sys and bin:bin explicit, so that the
xfs tests that source common/dump and rely on _do_create_dumpdir_fill
and _create_dumpdir_symlinks do not fail on chown when those
users/groups are missing.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
_require_group greps for the required group string in /etc/group but
this can partially match other groups or group member names and falsely
return success where it should fail.
Make the regex more specific so that it can unambigiously match only the
exact group name rather than any other group that happens to match as a
substring or any matching username from the group member list field.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test calculates the amount of free space on a filesystem and uses
the block size to spread the work of filling the free space among a
bunch of threads. Unfortunately, the test /should/ be using the
allocation unit size, not the fs block size, which is why this test
fails on configurations such as XFS realtime with a 28k extent size.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Leah Rumancik <leah.rumancik@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Make it possible to always run all the tests in the testsuite that don't
require idmapped mounts. Now all filesystems can benefit from the
generic vfs tests that we currently implement. This means setgid
inheritance and other tests will be run for all filesystems not matter
if they support idmapped mounts or not.
To this end, the binary makes use of the fs_allow_idmap() helper we
introduced earlier to dynamically determine whether the underlying
filesystem supports idmapped mounts or not. It is therefore safe for
callers to call the binary even if the tested filesystem doesn't support
idmapped mounts.
Most of the tests that call the idmapped mount binary require idmapped
mount support and so they will continue to call
_require_idmapped_mounts. This will also ensure that we log a proper
message about skipping a whole test.
However, the generic/633 test includes idmapped mount specific and
generic tests. The generic tests can and should always be executed as
they test core vfs functionality that isn't tested anywhere else in
fstests. So here we can remove the _require_idmapped_mounts check from
the test and rely on the binary doing the right thing.
Link: https://lore.kernel.org/r/20220113132421.865002-2-brauner@kernel.org
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fstests@vger.kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Move the check whether the underlying filesystem supports idmapped
mounts into a separate helper. We will use it in the following patch to
make it possible to always run all tests that don't require idmapped
mounts.
Link: https://lore.kernel.org/r/20220113132421.865002-1-brauner@kernel.org
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fstests@vger.kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
With the recent ext4 mount api change we discovered a bugs that weren't
caught by this test. It was triggered by remounting the file system
either with the same mount options, or without specifying any mount
options at all. In this case we would expect the original mount options
to remain the same, however this was either not the case, or the remount
failed.
Add a remount test after a regular mount. Remount once with specifying
the original mount option and remount second time without specifying
anything. Test the active options after each test.
Additionally include all the combinations of data= options in the
remount test for the sake of completeness.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test that defragging files with very small sizes works and does not
result in any crash, hang or corruption.
This is motivated by a regression introduced in kernel 5.16 where
attempting to defrag a file with a size of 1 byte would result in
the kernel code hitting an "infinite" loop (iterating from 0 to
(u64)-1 in increments of 256K, which in practice is an eternity).
The regression is fixed by a patch with the following subject:
"btrfs: fix too long loop when defragging a 1 byte file"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test quota disable during btrfs balance and confirm it does not
cause kernel hang. This is a regression test for the problem
reported to linux-btrfs list [1].
The hang was recreated using the test case and memory backed
null_blk device with 5GB size as the scratch device, and fixed by
kernel patch titled
btrfs: fix deadlock between quota disable and qgroup rescan worker
[1] https://lore.kernel.org/linux-btrfs/20220115053012.941761-1-shinichiro.kawasaki@wdc.com/
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Zorro Lang reported that the _scratch_mkfs_sized call in the new xfs/107
fstest sometimes fails on more exotic storage due to insufficient log
size on account of raid stripes, etc. These are side effects of the
filesystem being too small.
Change the filesystem size to 256M to avoid these problems, and change
the allocstale parameters to use the same file size (16M) as before.
Given that ALLOCSP produces stale disk contents pretty quickly this
shouldn't affect the test runtime too much.
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Update this utility to use fallocate to preallocate/reserve space to a
file so that we're not so dependent on legacy XFS ioctls. Fix a minor
whitespace error while we're at it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
On my test machine, ext4/033 fails even use the non-overflow size.
It reports invalid new size when using strtoull because errno is 1.
As man-pages said "Since strtoul() can legitimately return 0 or ULONG_MAX
(ULLONG_MAX for strtoull()) on both success and failure, the calling program
should set errno to 0 before the call, and then determine if an error occurred
by checking whether errno has a nonzero value after the call".
So add a step to set errno to 0 before strtoull call.
Fixes: 92b9c0dedace ("ext4/033: test EXT4_IOC_RESIZE_FS by calling the ioctl directly")
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This ioctl will be dropped soon, so port the program to use ftruncate,
which does the same thing.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Update this utility to use fallocate to preallocate/reserve space to a
file so that we're not so dependent on legacy XFS ioctls.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add support for this old ioctl before we remove it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add a regression test to check that XFS_IOC_ALLOCSP isn't handing out
stale disk blocks for preallocation.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
xfs/308 and xfs/130 are two tests that tried to mess with the refcount
btree to try to trip up the COW recovery code. Now that we've made COW
recovery only happen during log recovery, we must adjust these tests to
force a log recovery. Older kernels should be ok with this, since they
unconditionally try to recover COW on mount.
Add a helper function to unmount the filesystem with a dirty log and
convert the two tests to use it. While we're at it, remove an xfs_check
test because xfs_check refuses to run on a dirty fs, and nobody cares
about xfs_check anymore.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In commit 6ba125c9, we tried to adjust this fstest to deal with the
removal of the ability to turn off quota accounting via the Q_XQUOTAOFF
system call.
Unfortunately, the changes made to this test make it nonfunctional on
those newer kernels, since the Q_XQUOTARM command returns EINVAL if
quota accounting is turned on, and the changes filter out the EINVAL
error string.
Doing this wasn't /incorrect/, because, very narrowly speaking, the
intent of this test is to guard against Q_XQUOTARM returning ENOSYS when
quota has been enabled. However, this also means that we no longer test
Q_XQUOTARM's ability to truncate the quota files at all.
So, fix this test to deal with the loss of quotaoff in the same way that
the others do -- if accounting is still enabled after the 'off' command,
cycle the mount so that Q_XQUOTARM actually truncates the files.
While we're at it, enhance the test to check that XQUOTARM actually
truncated the quota files.
Fixes: 6ba125c9 ("xfs/220: avoid failure when disabling quota accounting is not supported")
Cc: xuyang2018.jy@fujitsu.com
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by:Yang Xu <xuyang2018.jy@fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
_check_xfs_scrub_does_unicode is still less than adequate -- if running
ldd to report the xfs_scrub binary's dynamic library dependencies
doesn't work, we could still detect support by grepping for strings that
only appear when the unicode checker is built.
Note that this isn't the final word on all of this; I will make this
easier to discover in a future xfs_scrub release.
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Btrfs/011 test case has exposed quite some bugs in the past, but it also
has some tendency to cause false alert, as its way testing replace
cancel require the replace to be still running when we send the cancel
request.
But on a lot of cases, the replace can finish way faster than the wait
time, and cause false alert.
Commit fa85aa64 ("btrfs/011: Fill the fs to ensure we have enough data for
dev-replace") tries to address the problem by filling the fs, but there
is still no guarantee.
Although there is still some discussion on how to properly solve the
problem, there is one thing sure that we should continue the test
instead of abort, if the replace cancel failed.
A quick abort caused by finished replace will leave other profiles
untested, reducing the coverage.
This patch will still mark the test failed for a finished replace, but
at least ensure we have run the test for all the profiles.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
mread copies data one-byte-at-a-time, so it may races with
reflink_range() who invalidates page cache of the dest file.
Allow this race by adjusting the egrep regexp.
Reported-by: Darrick J. Wong <djwong@kernel.org>
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Debian 10 uses ldd from glibc 2.28, where as Debian 11 uses ldd from
glibc 2.31. Sometime between glibc 2.28 and 2.31, ldd has been
changed so that the message "not a dynamic executable" is sent stderr,
where before it was sent to stdout. As a result, it caused
regressions for tests such as generic/453 which uses
_check_xfs_scurb_does_unicode:
generic/453 5s ... [22:42:03] [22:42:08]- output mismatch (see /results/xfs/results-4k/generic/453.out.bad)
--- tests/generic/453.out 2022-01-08 15:15:15.000000000 -0500
+++ /results/xfs/results-4k/generic/453.out.bad 2022-01-08 22:42:08.596982251 -0500
@@ -4,3 +4,4 @@
Test files
Uniqueness of inodes?
Test XFS online scrub, if applicable
+ not a dynamic executable
...
Fix this by sending stderr from ldd to /dev/null. This is not a
perfect solution, since it means that even if xfs_scrub was compiled
with libicui18n, we will skip the online scrub portion of generic/453.
However, this fixes the regression when runtime OS is changed from
Debian Buster to Debian Bullseye when xfsprogs is built statically.
In the long run, it would be nice if we could determine whether
xfs_scrub has unicode support without using ldd --- perhaps by
signally this in the output of xfs_scrub -V --- but we'll need to
discuss this with the xfsprogs maintainers.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In some setgid tests we missed to check ownership right after file or
directory creation in order to verify whether gid ownership inheritance
from the parent directory to the newly created file or directory works
correctly. Add the missing ones.
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fstests@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The explanations before were a bit thin and people not familiar with
setgid inheritance might get confused. Make it easier to understand the
tests.
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fstests@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
There's another call to fchownat() right above it so we really don't
need the second one.
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fstests@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Some tests on ceph require changing the layout of new files, which
is forbidden when the files are encrypted. Skip these tests if the
test_dummy_encryption mount option is being used.
Generalize the _exclude_scratch_mount_option code and add a new
_exclude_test_mount_option call as well. Call the new function from the
ceph tests that should exclude test_dummy_encryption.
Cc: Luis Henriques <lhenriques@suse.de>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Luis Henriques <lhenriques@suse.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Cephfs is introducing a new mount device syntax. Fix the fstests
infrastructure to handle the new syntax correctly.
Cc: Zorro Lang <zlang@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test checks that speculative file preallocations are transferred to
threads writing other files when space is low. Since we have background
threads to clear those preallocations, it's possible that the test
program might not get a speculative preallocation on the first try.
This problem has become more pronounced since the introduction of
background inode inactivation since userspace no longer has direct
control over the timing of file blocks being released from unlinked
files. As a result, the author has seen an increase in sporadic
warnings from this test about speculative preallocations not appearing.
Therefore, modify the function to try up to five times to create the
speculative preallocation before emitting warnings that then cause
golden output failures.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test case needs two scratch fs. For debugging purposes, a fsid is
kept known. However, mkfs-btrfs has a stringent and inconsistent
approach, to check if that fsid is already present on any of the other
disks in the system. (This does not apply to the virtual devices in the
system).
To avoid running into the non-unique fsid found error, remove the known
fsid.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This poorly implemented test runs fsstress and embeds xfs_quota output
in the golden output. This means that it breaks as soon as anyone adds
a new operation to fsstress, since that perturbs the sequence of
operations that it runs, which will make the project quota report output
change.
Normally I'd just fix the test, but the golden output also encodes
output strings that xfs_quota hasn't printed since 2010. Clearly
nobody's running this test (including me, who has had it turned off for
five+ years) so just get rid of it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Recreating a new filesystem or adding a device to a mounted the
filesystem should remove the device entries under its previous fsid
even when confused with different device paths to the same device.
Fixed by the kernel patch (in the ml):
btrfs: harden identification of the stale device
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test for races or FS corruption when mmap writing to a file that's also
the target of a reflink operation. (MMAP version of generic/168,170)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test for races or FS corruption when mmap writing to a file that's
also the source of a reflink operation. (MMAP version of generic/167,
166)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test for races or FS corruption between reflink and mmap reading the
target file. (MMAP version of generic/164,165)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range
originally covers multiple extents, mixed with reflinked, unwritten,
hole, regular and delalloc blocks.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in direct-io mode works when the CoW
range originally covers multiple extents, mixed with reflinked,
unwritten, hole, regular and delalloc blocks.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in buffered mode works when the CoW
range originally covers multiple extents, mixed with reflinked,
unwritten, hole, regular and delalloc blocks.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode to the source file when the CoW range
covers delalloc blocks and regular shared blocks.
(MMAP version of generic/293,295)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode to the source file when the CoW range
covers holes and regular shared blocks.
(MMAP version of generic/291,292)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode to the source file when the CoW range
covers unwritten and regular shared blocks.
(MMAP version of generic/289,290)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode to the source file when the
CoW range covers regular unshared and regular shared blocks. (MMAP
version of generic/284,287)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range
originally covers multiple extents, mixed with reflinked, unwritten,
hole, regular and delalloc blocks. (MMAP version of generic/200,199)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range
originally covers multiple extents, some delalloc, some not. (MMAP
version of generic/195,194)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Check whether delalloc is supported on current device.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range
originally covers multiple extents, some holes, some not. (MMAP
version of generic/191,190)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range
originally covers multiple extents, some unwritten, some not. (MMAP
version of generic/189,188)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range originally
covers multiple extents, some regular, some not.
(MMAP version of generic/197,196)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensuring that copy on write in mmap mode works when the CoW range originally
covers multiple extents. (MMAP version of generic/185,183)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
E2fsprogs commits 4ea80d031c7e ("resize2fs: adjust new size of the
file system to allow a successful resize") and 50088b1996cc
("resize2fs: attempt to keep the # of inodes valid by removing the
last bg") will automatically reduce the requested new size of the file
system by up to a single block group to avoid overflowing the 32-bit
inode count. This interferes with ext4/033's test of kernel commit
4f2f76f75143 ("ext4: Forbid overflowing inode count when # resizing".)
Address this by creating a new test program, ext4_resize which calls
the EXT4_IOC_RESIZE_FS ioctl directly so we can correctly test the
kernel's online resize code.
Reported-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The `core_pattern' and `ulimit_c' variables must be set to
restore their original values in case _cleanup fires early.
Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The mmap-rw-fault test program used by generic/647 uses O_DIRECT
unconditionally.
Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The quota index information in the image is tampered, causing
illegal memory access.
It is a regression test for kernel commits
- 9bf3d2033129 quota: check block number when reading the block in quota file
- d0e36a62bd4c quota: correct error number in free_dqentry()
Signed-off-by: Sun Ke <sunke32@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test that COW writeback that overlaps non-shared delalloc blocks
does not leave around stale delalloc blocks on I/O failure. This
triggers assert failures and free space accounting corruption on
XFS.
Fixed by upstream kernel commit 5ca5916b6bc9 ("xfs: punch out data
fork delalloc blocks on COW writeback failure").
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This is needed to account for bash 5.1 adding line number annotation
when executing a command via the -c option and it fails. For example,
"bash -c 'echo foo > /'" will cause bash 5.1 to report:
bash: line 1: /: Is a directory
instead of:
bash: /: Is a directory
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The test is relying on the fact that an fsync on directory "a" will
result in persisting the changes of its subdirectory "b", namely the
rename of "/a/b/foo" to "/c/foo". For this particular filesystem layout,
that will happen on btrfs, because all the directory entries end up in
the same metadata leaf. However that is not a behaviour we can always
guarantee on btrfs. For example, if we add more files to directory
"a" before and after creating subdirectory "b", like this:
mkdir $SCRATCH_MNT/a
for ((i = 0; i < 1000; i++)); do
echo -n > $SCRATCH_MNT/a/file_$i
done
mkdir $SCRATCH_MNT/a/b
for ((i = 1000; i < 2000; i++)); do
echo -n > $SCRATCH_MNT/a/file_$i
done
mkdir $SCRATCH_MNT/c
touch $SCRATCH_MNT/a/b/foo
sync
# The rest of the test remains unchanged...
(...)
Then after fsyncing only directory "a", the rename of file "foo" from
"/a/b/foo" to "/c/foo" is not persisted.
Guaranteeing that on btrfs would be expensive on large directories, as
it would require scanning for every subdirectory. It's also not required
by posix for the fsync on a directory to persist changes inside its
subdirectories. So add an explicit fsync on file "foo" when the filesystem
being tested is btrfs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
A mismerge during a git rebase some time ago broke fsstress in my
development tree, because it added OP_XCHGRANGE into the opt_y typedef
definition at a different offset than the actual entry in the ops array.
This broke the relationship ops[i].op == i.
Since most of fsstress.c blindly assumes that it's ok to index the ops
array by OP_ type, this off-by-one error meant that when I created an
fstest with "-f unlink=1", it actually set the frequency of the adjacent
operation (unresvsp) to 1. I didn't notice this until I started to
investigate how a filesystem created with "-z -f creat=4 -f unlink=4"
could end up with 1.8 million files after 30 seconds.
Eliminate the possibility for future screwups like this by using indexed
array initializers. This enables us to remove the separate op field in
struct opdesc, for a minor savings of memory footprint and reduction in
footgun opportunity.
While we're at it, reformat the ops table to be more pleasing to the
eye.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
When module is not present and the open coded patient module
remover is called we'll end up in a loop which never ends.
Fix this.
I actually found this issue not in fstests, but when applying this
open coded solution to blktests. In fstest we tend to only call
module remove when we have a module loaded. blktests is different,
and so I immediately spotted the issue there.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add new testcase for testing the new btrfs sysfs knob to change the
chunk size. The new knob uses /sys/fs/btrfs/<UUID>/allocation/<block
type>/chunk_size.
The test case implements three different cases:
- Test allocation with the default chunk size
- Test allocation after increasing the chunk size
- Test allocation when the free space is smaller than the chunk size.
Note: this test needs to force the allocation of space. It uses the
/sys/fs/btrfs/<UUID>/allocation/<block type>/force_chunk_alloc knob.
Testing:
The test has been run with volumes of different sizes.
Signed-off-by: Stefan Roesch <shr@fb.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test that send and balance can run in parallel, without failures and
producing correct results.
Before kernel 5.3 it was possible to run both operations in parallel,
however it was buggy and caused sporadic failures due to races, so it was
disabled in kernel 5.3 by commit 9e967495e0e0ae ("Btrfs: prevent send
failures and crashes due to concurrent relocation"). There is a now a
patch that enables both operations to safely run in parallel, and it has
the following subject:
"btrfs: make send work with concurrent block group relocation"
This also serves the purpose of testing a succession of incremental send
operations, where we have a bunch of snapshots of the same subvolume and
we keep doing an incremental send using the previous snapshot as the
parent.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
We have always failed generic/260, because it tests to see if the file
system will reject a trim range that is above the reported fs size.
However for btrfs we will happily remap logical byte offsets within the
file system, so you can end up with bye offsets past the end of the
reported end of the file system. Thus we do not fail these weird
ranges. We also don't have the concept of allocation groups, so the
other test that tries to catch overflow doesn't apply to us either.
Fix this by simply using an offset that will fail (once a related
kernel path is applied) for btrfs. This will allow us to test the
different overflow cases that do apply to btrfs, and not muddy up
test results by giving us a false negative for the cases that do not
apply to btrfs.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Acked-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This test fails on my overnight tests that use zlib, because the
data usage doesn't get high enough for the fstrim math to work out.
We are testing that fstrim properly trims the while file system when the
block groups are relocated to > total_bytes. However it tries to
validate this by making sure that we trim > total_bytes / 2, which we
won't with compression on because we won't actually allocate total_bytes
/ 2. The free extents that are trimmed in the first go around don't get
trimmed the second time. With some compression algorithms we move the
free extents around enough that they'll get re-trimmed and thus pass,
but others it won't work out properly. Simply require that we don't
have compression enabled so that the results are consistent.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Insert the extent entry in ext4_ext_insert_extent() (to be inserted at
the beginning of the block). In the stage of updating the starting block
number of the parent index block, an error happened
in ext4_ext_correct_indexes()->ext4_ext_get_access(), which caused the
index update of the parent index node to fail. The ext4_ext_insert_extent()
function exits directly and does not roll back the extent entry of
the leaf block. Eventually, the extent starting block numbers in
the index block and leaf block are inconsistent, triggering bugon.
This is a regression test for three kernel commit:
1. 0f2f87d51aebc (ext4: prevent partial update of the extent blocks)
2. 9c6e071913792 (ext4: check for inconsistent extents between index
and leaf block)
3. 8dd27fecede55 (ext4: check for out-of-order index extents in
ext4_valid_extent_entries())
Signed-off-by: Chen Long <chenlongcl.chen@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
As kernel commit e93a5e9306a5 ("NFSv4: Add support for application
leases underpinned by a delegation") describes, NFS now supports
file leases only after delegations. However, fstests lacks many NFS
functionalities including delegation.
So let's skip generic/571 if locktest -t on NFS returns EAGAIN
because of commit df2c7b951f43 ("NFSv4: setlease should return
EAGAIN if locks are not available").
Signed-off-by: Su Yue <suy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Since kernel commit d4088803f511 ("btrfs: subpage: make lzo_compress_pages()
compatible"), lzo compression no longer respects the max compressed page
limit, and can cause kernel crash.
The upstream fix is 6f019c0e0193 ("btrfs: fix a out-of-bound access in
copy_compressed_data_to_page()").
This patch will add such regression test for all possible compress-force
mount options, including lzo, zstd and zlib.
And since we're here, also make sure the content of the file matches
after a mount cycle.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Ensure a device can be added to a filesystem that has a paused balance
operation and has been mounted with the 'skip_balance' mount option
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
We hit spurious errors with generic/274 with compression on because we
attempt to fill up the disk with small writes, and these writes end up
taking up metadata space instead of data space. Thus when we go to
write into the preallocated area we get an ENOSPC, but from the metadata
side and not the data side. Simply skip this test if we have
compression enabled.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The btrfs utils are printing a status message about TRIM'ing device on
replace and this is throwing off the golden output, redirect stdout from
'device replace start' to $seqres.full so we don't get false negatives.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Since bb0ab7b2 ("common/rc: Enable _format_swapfile to return the swap
size") we started echo'ing out the swap file size, which is polluting
the golden output for btrfs/176 causing it to fail. Fix this by
redirecting the output to /dev/null.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In 5.16 we removed the xfs_dsb, xfs_dqblk, and xfs_dinode typedefs,
which means that we need to list the non-typedef struct definitions
explictly in the golden output for this test.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
A change to btrfs-progs uncovered a problem with btrfs/099, we weren't
specifying the qgroupid with the subvol id. This technically worked
before but only by accident, and all other tests properly specify the
qgroupid for qgroup limit commands. Fix this test to specify the
qgroupid, which will work with older versions of btrfs-progs and newer
ones as well.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This is a regression test for the fix in [1]. The test makes sure that
setattr behaves correctly on idmapped mounts that make use of circular
mappings. Such mappings may e.g. be used to allow two users to share
home directories through the same idmapped mount. The tests are
explained in detail in code comments.
[1]: commit 968219708108 ("fs: handle circular mappings correctly")
Cc: Seth Forshee <seth.forshee@digitalocean.com>
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fstests@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Our nightly xfstests runs exposed a set of tests that always fail if we
have compression enabled. This is because compression obviously messes
with the amount of data space allocated on disk, and these tests are
testing either that quota is doing the correct thing, or that we're able
to completely fill the file system.
Add a helper to check to see if we have any of our compression related
mount options set and simply _not_run for these specific tests.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
I updated btrfs-progs on all my test runners and started failing tests
because I was getting the TRIM messages in the golden output. There
were fixes that went in recently to properly detect TRIM support which
resulted in extra messages being printed. Fix this by redirecting
stdout to $seqres.full for all 'btrfs device add' calls. If anything
fails we'll still pollute the output, but normal status messages will
get properly eaten.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The code that creates files and moves them to low/high inode number
files writes different file contents before doing the move - leading to
non-reproducible results.
Fix this by writing the file contents after moving them to high/low
inode number files.
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Check what happens if we MMAP CoW blocks 2-4 of a page's worth of blocks when
the surrounding blocks vary between unwritten/regular/delalloc/hole.
(MMAP version of generic/229,238)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Check what happens if we MMAP CoW blocks 2-4 of a page's worth of blocks when
the second block is delalloc. (MMAP version of generic/222,227)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Check what happens if we MMAP CoW blocks 2-4 of a page's worth of blocks when
the second block is a hole. (MMAP version of generic/218,220)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Check what happens if we MMAP CoW blocks 2-4 of a page's worth of blocks when
the second block is a unwritten block. (MMAP version of generic/216,217)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Check what happens if we MMAP CoW blocks 2-4 of a page's worth of blocks when
the second block is a regular block. (MMAP version of generic/205,206)
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
In the coming btrfs-progs v5.15 release, mkfs.btrfs will change to
use v2 cache by default.
However nospace_cache mount option will not work with v2 cache, as
it would make v2 cache out of sync with on-disk used space.
So mounting a btrfs with v2 cache using "nospace_cache" will make
btrfs to reject the mount.
There are quite some test cases relying on nospace_cache to prevent
v1 cache to take up data space.
For those test cases, we no longer need the "nospace_cache" mount
option if the filesystem is already using v2 cache. Since v2 cache
is using metadata space, it will no longer take up data space, thus
no extra mount options for those test cases.
By this, we can keep those existing tests to run without problem for
both v1 and v2 cache.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
I use lvm to carve up a large disk so I can run the btrfs raid related xfstests.
However this messes with tests that try to greate lvm devices ontop of
SCRATCH_DEV. Handle this by adding a _require_scratch_nolvm helper to skip
tests that are going to try and create lvm devices.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
My nightly btrfs tests are failing on my configs with -o compress because the
extents have FIEMAP_EXTENT_ENCODED set, which throws the golden output off.
Fix this by changing the filter helper to spit out symbolic names for SHARED and
LAST (these tests only care about SHARED). Then change the golden output to
match the new output of the filter. With this patch my -o compress configs now
pass these tests.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Currently this test fails on ext2 and ext3 filesystems using 1k block sizes,
because we set the maximum swap size the kernel is allowed to map according to
the mapping kernel created when enabling the original swap file.
But the translation from indirect block mapping to iomap extents associated with
the page alignment requirements imposed by iomap_swapfile_add_extent(), causes
this test to fail. The kernel end up mapping way less pages than the file
actually has.
After the file is extended by the test, the page alignment is not a problem
anymore and the kernel can use the whole space available in the swapfile,
written in its header, and this creates a variance bigger than what the current
test allows, making the tolerance check within the test to fail.
Fix this by using the swap size recorded in the swapfile header (reported by
mkswap), as the maximum swap size the kernel is allowed to map, instead of
reading the swap size mapped by the kernel from /proc. This also makes
the first swap{on/off} cycle unnecessary, so remove it.
Since the size hardcoded in the swapfile header is the limit allowed for the
kernel to map as swap area, this is the real limit the kernel can't map beyond,
and what this test should be checking for.
This patch also slightly changes the way the test check the swap size
'after' the swap file is extended. Instead of retrieving the information
from /proc/swaps directly, the test now relies on 'swapon' tool. This
enables the test to retrieve the swap size in bytes directly, same unit
returned by _format_swapfile. This avoid possible miscalculations caused by
retrieving swap size in different units.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Once the kernel is free to not map the full swap file during a swapon call,
it can be useful to know the exact size of the swap area created during
_format_swapfile().
To achieve this, it is needed to change other _format_swapfile() callers to drop
the return value if not required, otherwise, it will be printed to stdout making
such tests to fail.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Instead of using $TEST_DIR/$$, use the _correct_ way to create temporary
directories. I've seen generic/626 failing with:
QA output created by 626
mkdir: cannot create directory '/media/test/471': File exists
Silence is golden
which was likely due to another test that used the same directory name and
didn't do the clean-up.
Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add test to validate that all the ext4, ext3 and ext2 are properly
recognized, validate and applied to avoid regressions as ext4 moves to
the new mount API.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Add _require_kernel_config() and _has_kernel_config() helpers to check
whether a specific kernel configuration is enabled on the kernel.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
ext4/051 fails on my test machine, but I can't find commit in
e2fsprogs according to commit log that said it is a e2fsprog
regression test. Actually, it is a kernel regression test. So
remind user it is a kernel regression test and use correct fix
kernel commit[1].
[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2bbb92f
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Sometimes g/648 fail to unmount dmerror with this error:
umount: /mnt/xfstests/scratch: target is busy.
Even worse, it will cause all later test cases fail as:
mount: bad usage
Try 'mount --help' for more information.
check: failed to mount $SCRATCH_DEV using specified options
Interrupted!
So we shouldn't _fail directly if dmerror_unmount fails, use a while
loop to try to unmount it enough times.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
One of the test cases in generic/574 tests that if a file of length
130999 has fs-verity enabled, and if bytes 131000..131071 (i.e. some
bytes past EOF and in the same block as EOF) are corrupted with nonzero
values, then reads of the corrupted part should fail with EIO.
This isn't a valid test case, because reads that start at or past EOF
are allowed to simply return 0 without doing any I/O.
Therefore, don't run this test case.
This fixes a test failure caused by the kernel commit 8c8387ee3f55
("mm: stop filemap_read() from grabbing a superfluous page").
Note that the other test cases for this same corrupted file remain
valid, including testing that an error is reported during full file
reads and during mmap "reads". This is because the fs-verity Merkle
tree is defined over full blocks, so the file's last block won't be
readable if it contains corrupted (nonzero) bytes past EOF. This may
seem odd, but it's working as intended, especially considering that
bytes past EOF in a file's last block are exposed to userspace in mmaps.
Signed-off-by: Eric Biggers <ebiggers@google.com>
|
|
Filesystems timestamps granularity can cause spurious test failures:
QA output created by 528
btime has value of 1635818936
btime is NOT in range 1635818937 .. 1635818942
This test output makes it looks like $testfile was created *before* the
'date' command was executed. What really happen was that btime was
truncated according to the granularity defined by filesystem (I've seen
this with both ext4 and xfs, but I guess others are also affected).
Since granularity can't be worse than a second, simply adjust the test
tolerance interval by 1 second.
Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
btrfs/249 fails with:
QA output created by 249
./common/btrfs: line 425: _require_loadable_fs_module: command not found
./common/btrfs: line 432: _reload_fs_module: command not found
ERROR: not a btrfs filesystem: /media/scratch
This is because the test is failing to source common/module.
Fix this by sourcing common/module in the btrfs common file.
While it it remove duplication of sourcing this file from other
tests in btrfs so that this is only done once in one place.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
I ran into an error with generic/083 with xfs due to check_cwd() but
why it failed is not clear because there are two types of
failures:
o stat64() failed (likely -ENOMEM is my guess)
o the inode actually changed
Throw a bone out to developers so that in case en error does happen
they know which rabbit hole to go into.
Cc: Anthony Iliopoulos <ailiopoulos@suse.de>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Now that storage has gotten really really fast, we have to crank up
TIME_FACTOR to amusingly huge values to do things such as 10-day soak
testing. "Un"fortunately, fsstress uses 'int' to count operations,
which means we get close to maxing out the 2^31 limit on operations in
fsstress. Widen it to a long long value to take us to the heat death of
the universe, like we did for fsx a while back. ;)
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Current check is buggy because it can never trigger as even if
SCRATCH_DEV_POOL is not defined config_ndevs will get a value of 0
from 'wc -w', this in turn makes 'typeset -p config_ndevs' always
return 0, triggering the existing check a noop.
Fix this by explicitly checking for the presence of SCHRATC_DEV_POOL
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
This case is test for 'unlink', and there is no umount operation here.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
1. update description according to the current testcase
2. "ENSPC" -> "ENOSPC" ,"an the end -> at the end"
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
The original 'file3' is used to check if the result after operation on
file2 is correct. So, rename it to be 'file2.chk' to make it easier to
understand.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Test that if we write to a range of a NOCOW file that has allocated
extents and there is not enough available free space for allocating new
data extents, the write succeeds. Test for direct IO and buffered IO
writes.
This currently fails on btrfs for the direct IO write scenario, only, but
while at it also test a buffered IO write, to help prevent regressions in
the future.
The patch that fixes the direct IO case has the following subject:
"btrfs: fix ENOSPC failure when attempting direct IO write into NOCOW range"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
_cleanup_flakey can be called even when _init_flakey hasn't been called.
For example, _require_flakey_with_error_writes does this.
Unfortunately, the patch to add support for external logs and rt devices
will "reset" the SCRATCH_LOGDEV/SCRATCH_RTDEV variables without noticing
that _init_flakey hasn't been called yet. When this happens, those two
variables will be set to the empty string, with the result that the rest
of the test doesn't use those devices.
To fix this, only reset SCRATCH_LOGDEV/RTDEV to the "NON_FLAKEY" value
if we actually set one.
Fixes: 9c1f3149 ("dmflakey: support external log and realtime devices")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
Recent changes have turned off all dm-error, dm-thin and dm-flakey
tests on pmem devices even when we are not explicitly testing DAX.
This is a regression resulting in a large number of log recovery
tests no longer running on my pmem-based test VMs. I added the "-o
dax=never" mount options to these test configs, only to find it
still would not run the dm tests even though the filesystem will
never use DAX.
Fix this so that the dm target DAX test explicitly ignores the
the block device DAX capability when the filesystem is mounted with
dax=never and hence we can use all the dm targets when the tests are
being run with FSDAX disabled.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
move '_require_fs_space' after mounted.
==before patch==
btrfs/012 [not run] This test requires at least 0GB free on /fs/scratch to run
==after patch==
btrfs/012 189s ... 194s
Ran: btrfs/012
Passed all 1 tests
Signed-off-by: Zhu Yifei <yifeix.zhu@intel.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|
|
inode cache feature has been removed
Link: https://www.spinics.net/lists/linux-btrfs/msg107910.html
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ma Xinjian <xinjianx.ma@intel.com>
Acked-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
|