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>
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>
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>
Last night I had xfstests running and after a while it hung at
shared/032 because I had reiser4progs installed and it was waiting
for input:
-----------------------------------------------------------------
mkfs -t reiser4 /dev/ram0
mkfs.reiser4 1.2.1
Format release: 4.0.2
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
reiser4progs/COPYING.
Block size 4096 will be used.
Linux 5.5.0-rc5-amd64 is detected.
Uuid 2006a590-832a-49f5-9317-cf91bf866dd7 will be used.
Reiser4 is going to be created on /dev/ram0.
(Yes/No):
-----------------------------------------------------------------
The patch below adds an option (cf. reiserfs the line above) so that
the test continues.
Curiously enough the test still "succeeds" for reiser{fs,4} (and jfs
too) because the userspace tools don't appear to have a routine to
check for "contains an existing filesystem", but that could be
addressed in a different patch.
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Try to punch hole with unaligned size and offset when the FS is full
and mounted with nodatacow option.
Mainly holes are punched at locations which are unaligned with the
file extent boundaries when the FS is full by data. As the punching
holes at unaligned location will involve truncating blocks instead
of just dropping the extents, it shall involve reserving data and
metadata space for delalloc and so data alloc fails as the FS is
full.
btrfs_punch_hole()
btrfs_truncate_block()
btrfs_check_data_free_space() <-- ENOSPC
We don't fail punch hole if the holes are aligned with the file
extent boundaries as it shall involve just dropping the related
extents, without truncating data extent blocks.
This test was orignally merged as btrfs/172 (commit 4c2c678cd), then
Iremoved by commit 538d8a4bcc. But it's decided to bring back this
test case, now the problem is better understood and the fix is
available in the ML as below.
Link: https://patchwork.kernel.org/patch/11357415/
Reviewed-by: Filipe Manana <fdmanana@suse.com>
(cherry picked from commit 4c2c678cd5)
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When btrfs/022 fails, its $seqres.full doesn't contain much useful info
to debug.
This patch will add extra debug, including subvolid and full "btrfs
qgroup show" output.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
Btrfs/022 sometimes fails with snapshot's reference mismatch with its
source.
[CAUSE]
Since commit fd08309295 ("fsstress: add the ability to create
snapshots") adds the ability for fsstress to create/delete snapshot and
subvolumes, fsstress will create new subvolumes under test dir.
For example, we could have the following subvolumes created by fsstress:
subvol a id=256
subvol b id=306
qgroupid rfer excl
-------- ---- ----
0/5 16384 16384
0/256 13914112 16384
...
0/263 3080192 2306048 << 2 *306* 048
...
0/306 13914112 16384 << 0/ *306
So when we're greping for subvolid 306, it matches qgroup 0/263 first,
which has difference size, and caused false alert.
[FIX]
Instead of greping "$subvolid" blindly, now grep "0/$subvolid" to catch
qgroupid correctly, without hitting rfer/excl values.
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
`seq X Y` will print all numbers between X and Y, including Y. Since
inode chunks contain inodes numbered from X to X+63, we need to set the
loop variables correctly.
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>