The minimum accepted allocsize mount option value is page size, which
causes the particular test to fail in architectures where page size >
block size. Fix it by basing the value on the platform page size rather
than the block size as obtained from mkfs. In addition add a filter so
that different values can be used without breaking the golden output.
Signed-off-by: Anthony Iliopoulos <ailiopoulos@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We are never using the FALLOC_FL_KEEP_SIZE flag for zero range operations
even when we intend to use it. So fix it by setting that flag for the
call to fallocate(2) if the 'keep_size' parameter is true.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create a helper to run xfs_admin on the scratch device, then
refactor all tests to use it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If xfs_io's utimes command cannot interpret the arguments that are
given to it, it will print out "Bad value for [am]time". Detect
when this happens and drop the file out of the test entirely.
This is particularly noticeable on 32-bit platforms and the largest
timestamp seconds supported by the filesystem is INT_MAX. In this
case, the maximum value we can cram into tv_sec is INT_MAX, and
there is no way to actually test setting a timestamp of INT_MAX + 1
to test the clamping.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Apparently we don't have any tests which exercise the code path in
Btrfs that has to split up direct I/Os for RAID stripes. Add one to
catch the bug fixed by "btrfs: fix RAID direct I/O reads with
alternate csums".
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Recently LTP upstream removed some ext4 tests[1]. And two of them
is still valid to keep. So I transport those two tests here.
ext4-nsec-timestamps, which is used to test nanosec timestamps of
ext4, rewrite into ext4/043 and 044. ext4-subdir-limit, which is
used to test subdirectory limit of ext4, rewrite into ext4/045.
[1] https://marc.info/?l=linux-fsdevel&m=157190623919681&w=2
Signed-off-by: Sun Yong <yosun@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test currently assumes a file system block size of 4k. It will
work just fine on any user-specified block size, though.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Move the check for dax from the individual target scripts into
_require_dm_target. This fixes up a couple of missed tests that are
failing due to the lack of dax support (such as tests requiring
dm-snapshot).
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A handful of minor changes went into xfs_repair output in the
last push, so add a few more filters and change the resulting
expected output.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Now we just kill fdatasync_work process and wait nothing after the
test, so a busy unmount failure may appear if the fdatasync syscall
doesn't return in time.
umount: /tmp/scratch: target is busy.
mount: /tmp/scratch: /dev/sdb already mounted on /tmp/scratch.
!!! failed to remount /dev/sdb on /tmp/scratch
This patch waits the xfs_io fdatasync subprocess exit to make sure
_check_scratch_fs success.
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Generic/484 tests functionality that isn't really related to file
systems, and has failed every since it was added. Remove it as it
serves no puropse in xfstests.
[Eryu: also remove src/t_locks_execve.c and its entries in
src/Makefile and .gitignore]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a testcase for a corner that I missed when trying to fix gap
extents for btrfs. We would end up with gaps if we hole punched past
isize and then extended past the gap in a specific way. This is a
simple reproducer to show the problem, and has been properly fixed by my
patches now.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test several scenarios of cloning operations where the source range
includes inline extents. They used to not be supported on btrfs
because their implementation was not straightforward, and therefore
these operations used to fail with errno EOPNOTSUPP on older
kernels.
This currently fails on any released kernel. It passes only when the
patch with the following subject is applied:
"Btrfs: implement full reflink support for inline extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test case, btrfs/112, tests that some clone operations that have a
range covering inline extents fail with either -EOPNOTSUPP or -EINVAL.
These cases were unsupported on btrfs because they used to lead to file
corruptions and were not trivial to implement.
But there's now a patchset that adds support for them, and the relevant
patch of that patchset has the following subject:
"Btrfs: implement full reflink support for inline extents"
So just remove these tests from test case btrfs/112, since this test
case is about testing only the unsupported reflink operations. A new
test case that verifies that these cases now work, as long as some other
new cases, will follow in another patch.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This allows us to run all those tests which simulate disk failures
using dmerror.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When I test this case(default lsunit 256k), this case will fail,
as below:
cycle: 1 version: 2 lsn: 1,0 tail_lsn: 1,0
length of Log Record: 258048 prev offset: -1 num ops: 1
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extended-header: cycle: 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
It reports this info because xfs_logprint only read 32k header every time, so it
needs to read more times. We can filter this useless info.
common/log also has _filter_logprint function. only library function is
prefixed with "_", remove '_'.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test exercises obsolete ext4-specific functionality that will be
removed in the kernel's 5.7 release. Once that happens, ext4/002 will
always fail, so remove the test to avoid the noise.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On some systems btrfs/179 fails because the check finds that there
is difference in the qgroup counts.
So as the intention of the test case is to test any hang like
situation during heavy snapshot create/delete operation with quota
enabled, so make sure the qgroup counts are consistent at the end of
the test case, so to make the check happy.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
XFS is changing to suit the new mount API, so add this case to make
sure the changing won't bring in regression issue on xfs mount
option parse phase, and won't change some default behaviors either.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Now _require_btrfs_command can also check for subfuntion options, like
"subvolume delete --subvolid".
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a test which tests adding a key to a filesystem's fscrypt keyring
via an "fscrypt-provisioning" keyring key. This is an alternative to
the normal method where the raw key is given directly.
For more details, see kernel commit 93edd392cad7 ("fscrypt: support
passing a keyring key to FS_IOC_ADD_ENCRYPTION_KEY").
This test depends on an xfs_io patch which adds the '-k' option to the
'add_enckey' command, e.g.:
xfs_io -c "add_enckey -k KEY_ID" MOUNTPOINT
This test is skipped if the needed kernel or xfs_io support is absent.
This has been tested on ext4, f2fs, and ubifs.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For some encryption tests it's helpful to always use the same key so
that the test's output is always the same.
generic/580 already defines such a key, so move it into common/encrypt
so that other tests can use it too.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Anthony Iliopoulos
Filipe Manana
Darrick J. Wong
Omar Sandoval
Yong Sun
Jeff Moyer
Eric Sandeen
zhangyi (F)
Christoph Hellwig
Josef Bacik
Theodore Ts'o
Yang Xu
Eric Whitney
Anand Jain
Zorro Lang
Marcos Paulo de Souza
Eric Biggers