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>
Fix _require_xfs_io_command() to handle options that take arguments when
the argument is shown in the help text. E.g., it didn't work to run:
_require_xfs_io_command "add_enckey" "-k"
because the relevant line of the help text is:
-k KEY_ID -- ID of fscrypt-provisioning key containing the raw key
... but the grep command only matched "-k --", not "-k KEY_ID --".
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/128 whould fail with:
QA output created by 128
+su: warning: cannot change directory to /home/fsgqa: No such file or directory
Adjust README to create a home directory too. And (totally unrelated),
fix the 404 for the udf_test tool.
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
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>
Current _btrfs_get_subvolid() can't handle the following case at all:
# btrfs subvol list $SCRATCH_MNT
ID 256 gen 9 top level 5 path subv1
ID 257 gen 7 top level 256 path subv1/subv2
ID 258 gen 8 top level 256 path subv1/subv3
ID 259 gen 9 top level 256 path subv1/subv4
If we call "_btrfs_get_subvolid $SCRATCH_MNT subv1" we will get a list
of all subvolumes, not the subvolid of subv1.
To address this problem, we go egrep to match $name which starts with a
space, and at the end of a line.
So that all other subvolumes won't hit.
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Support 64-bit operation counts so that we can run long-soak tests for
more than 2 billion fsxops.
I figured that testcalls and simulatedopcount should both be signed
because numops is also signed. Granted, I guess numops is signed so
that we can set it to the magic value -1 and have fsx run "forever".
[Eryu: add Darrick's explanation about why we change testcalls to a
signed value.]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
`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>
If we can't create the 60T sparse image for testing repair on a large fs
(such as when running on 32-bit), don't bother running the rest of the
test. This requires the actual truncate(1) command, because it returns
nonzero if the system call fails.
[Eryu: the original bug was introduced by me when committing the
original patch, which was a correct fix. Sorry about that.. ]
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>
xfsprogs 5.4 prints "Discarding..." if the disk supports the trim
command. Filter this out of the output because xfs_info and friends
won't print that out.
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>
generic/581 passes for me, but Murphy Zhou reported that it started
failing for him. The part that failed is the part that sets the key
quota to the fsgqa user's current number of keys plus 5, then tries to
add 6 filesystem encryption keys as the fsgqa user. Adding the 6th key
unexpectedly succeeded.
What I think is happening is that because the kernel's keys subsystem
garbage-collects keys asynchronously, the quota may be freed up later
than expected after removing fscrypt keys. Thus the test is flaky.
It would be nice to fix this in the kernel, but unfortunately there
doesn't seem to be an easy fix, and the keys subsystem has always worked
this way. And it seems unlikely to cause real-world problems, as the
keys quota really just exists to prevent denial-of-service attacks.
So, for now just try to make the test more reliable by:
(1) Reduce the scope of the modified keys quota to just the part of the
test that needs it.
(2) Before getting the current number of keys for the purpose of setting
the quota, wait for any invalidated keys to be garbage-collected.
Tested with a kernel that has a 1 second sleep hacked into the beginning
of key_garbage_collector(). With that, this test fails before this
patch and passes afterwards.
Reported-by: Murphy Zhou <xzhou@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Murphy Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a test to validate that we're not adjusting up i_size before
we have the appropriate file extents on disk. We had a problem
where i_size would be adjusted up without a contiguous range of file
extents, which isn't ok without a special option enabled.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation works correctly when a file has
shared extents with itself in the send snapshot, with a hole between them,
and the file size has increased in the send snapshot.
This currently fails in 5.5-rc kernels (regression) but is fixed by a
patch that has the following subject:
Btrfs: send, fix emission of invalid clone operations within the same file
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a similar test to the existing one but with a file that has a
hardlink as well. This is motivated by a bug found in btrfs where
a fsync on a file that has the old name of another file results
in the logging code to hit an infinite loop. The patch that fixes
the bug in btrfs has the following subject:
"Btrfs: fix infinite loop during fsync after rename operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
As of the linux kernel commit fd0ddbe2509568 ("Btrfs: send, skip
backreference walking for extents with many references"), the test is no
longer dangerous and it's fast (takes 1 to 2 seconds on a modest vm with
a debug kernel). Therefore remove it from the dangerous group and add it
to the auto and quick groups as well.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Addition of fs-specific timestamp range checking was added
in 188d20bcd1eb ("vfs: Add file timestamp range support").
Add a check for whether the kernel supports the limits check
before running the associated test.
Based on an off-list discussion, we use a simpler interim approach
until fsinfo syscall would provide fs timestamp limits info.
This isn't perfect, but works for filesystems expiring in 2038.
Suggested-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If we can't create the 60T sparse image for testing repair on a large fs
(such as when running on 32-bit), don't bother running the rest of the
test.
[Eryu: use xfs_io instead of truncate]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Yang Xu
Eric Whitney
Anand Jain
Zorro Lang
Marcos Paulo de Souza
Eric Biggers
Christian Kujau
Qu Wenruo
Darrick J. Wong
Josef Bacik
Filipe Manana
Deepa Dinamani