This test uncovered 2 deadlocks with qgroups when their limit was
reached.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There are some btrfs test cases utilizing
_btrfs_forget_or_module_reload() to unregister all btrfs devices.
However _btrfs_forget_or_module_reload() will unregister all devices,
meaning if TEST_DEV is part of a multi-device btrfs, after those test
cases TEST_DEV will no longer be mountable.
This patch will introduce a new function, btrfs_rescan_devices() to undo
the unregister, so that all later test cases can mount TEST_DEV without
any problem.
Since we are here, also add a missing
_require_btrfs_forget_or_module_loadable for btrfs/225.
Reported-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that when using the NO_HOLES feature, if we truncate down a
file, clone a file range covering only a hole into an offset beyond
the current file size, and then fsync the file, after a power
failure we get the expected file content and we do not get stale
data corresponding to file extents that existed before truncating
the file.
This currently fails on btrfs and is fixed by commit 3660d0bcdb82
("btrfs: fix stale data exposure after cloning a hole with NO_HOLES
enabled")
[Eryu: add the commit id of the patch fixing the bug]
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There is a bug that, when btrfs is beyond qgroup limit, touching a file
could crash btrfs.
Such beyond limit situation needs to be intentionally created, e.g.
writing 1GiB file, then limit the subvolume to 512 MiB.
As current qgroup works pretty well at preventing us from reaching the
limit.
This makes existing qgroup test cases unable to detect it.
The regression is introduced by commit c53e9653605d ("btrfs: qgroup:
try to flush qgroup space when we get -EDQUOT"), and the fix is
commit 6f23277a49e6 ("btrfs: qgroup: don't commit transaction when
we already hold the handle")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1178634
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation correctly issues clone operations
for a file that had different parts of one of its extents cloned into
itself, at different offsets, and a large part of that extent was
overwritten, so all the reflinks only point to subranges of the extent.
This currently fails on btrfs but is fixed by a patch for the kernel that
has the following subject:
"btrfs: send, fix invalid clone operations when cloning from the same file and root"
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 verifies btrfs' free objectid management. I.e it ensures that
the first objectid is always 256 in an fs tree.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation succeeds, and produces the
correct results, after removing a directory and all its files, unmounting
the filesystem, mounting the filesystem again and creating a new file (or
directory).
This currently fails on btrfs, but is fixed by a patch that has the
following subject:
btrfs: send, fix wrong file path when there is an inode with a pending rmdir
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for the issue fixed by the kernel commit titled
"btrfs: correctly calculate item size used when item key collision happens"
In this case, we'll simply rename many forged filename that cause collision
under a directory to see if rename failed and filesystem is forced readonly.
Signed-off-by: ethanwu <ethanwu@synology.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This patch updates btrfs/215 to work with latest upstream kernel. That's
required since commit 324bcf54c449 ("mm: use limited read-ahead to satisfy read")
changed readahead logic to always issue a read even if the RA pages are
set to 0. This results in 1 extra io being issued so the counts in the
test should be incremented by 1. Also use the opportunity to update the
commit reference since it's been merged in the upstream kernel.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe noticed that btrfs/220 started failing with some mount option
changes I made recently, but upon closer inspection this test actually
fails in a lot of different ways normally, specifically if you specify
MOUNT_OPTIONS, or if you make an fs with the free space tree.
Address all these issues by reworking how we test that the mount options
are what we expect. First get what the default mount options are for a
plain mount of SCRATCH_DEV. This is used as the baseline, so no matter
how the mount options change in the future it will always work properly.
Secondly instead of specifying a rigid order of the mount options we're
testing, which breaks if we adjust the order in /proc/self/mounts,
simply specify the options we're actually interested in checking. Then
in the test function combine the common options with the new options
we're testing, and then combine that with our actual options and use
some sort magic to see if there's any difference. If there's no
difference then we know we have everything set as expected, if not we
fail.
This patch addresses the initial issue that Filipe noticed, but also
fixes the failures when you specified MOUNT_OPTIONS, or if you made the
fs with the free space tree.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some test cases are missing the 'rm -f $seqres.full' line but are appending
to that file, so everytime they run that file gets bigger and bigger (some
of them are using about a dozen megabytes on one of my test boxes).
So just add the 'rm -f $seqres.full' line to them, together with the comment
that the 'new' script generates for new test cases.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test several scenarios for RWF_NOWAIT writes, to verify we don't regress
on btrfs specific behaviour (snapshots, cow files, reflinks, holes,
prealloc extent beyond eof).
We had some bugs in the past related to RWF_NOWAIT writes not failing on
btrfs when they should or failing when they shouldn't, these were fixed by
the following kernel commits:
4b1946284dd6 ("btrfs: fix failure of RWF_NOWAIT write into prealloc extent beyond eof")
260a63395f90 ("btrfs: fix RWF_NOWAIT write not failling when we need to cow")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make this test case inline with the kernel patch [1] changes
[1] c6a5d954950c btrfs: fix replace of seed device
So use the sprout device as the replace target instead of the seed device.
This change is compatible with the older kernels.
While at this, this patch also fixes a typo fix as well.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for the issue fixed by the kernel commit
b5ddcffa3777 (btrfs: fix put of uninitialized kobject after seed device
delete).
In this test case, we verify the seed device delete on a sprouted
filesystem.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This new test will test btrfs's qgroup assign functionality. The
test has 3 cases.
- assign, no shared extents
- assign, shared extents
- snapshot -i, shared extents
Each cases create subvolumes and assign qgroup in their own way
and check with the command "btrfs check".
Cc: Qu Wenruo <wqu@suse.com>
Cc: Eryu Guan <guan@eryu.me>
Signed-off-by: Sidong Yang <realwakka@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Starting with version 2.41 of libcap, the output of the getcap program
changed and therefore some existing tests fail when the installed version
of libcap is >= 2.41 (the latest version available at the moment is 2.44).
The change was made by the following commit of libcap:
commit 177cd418031b1acfcf73fe3b1af9f3279828681c
Author: Andrew G. Morgan <morgan@kernel.org>
Date: Tue Jul 21 22:58:05 2020 -0700
A more compact form for the text representation of capabilities.
While this does not change anything about the supported range of
equivalent text specifications for capabilities, as accepted by
cap_from_text(), this does alter the preferred output format of
cap_to_text() to be two characters shorter in most cases. That is,
what used to be summarized as:
"= cap_foo+..."
is now converted to the equivalent text:
"cap_foo=..."
which is also more intuitive.
So add a filter to change the old format to the new one, an helper that
calls getcap with that filter, make existing tests use the new helper and
update their golden output to match the new output format of getcap.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
It appears that the goal of this case was to test balance and
replace concurrency. But these two operations aren't meant to run
concurrently and the replace failing errors are captured in the
seqres.full output. Which are expected errors. To avoid further
confusion, this patch adds comments. The reason to keep this
test case is at the Link.
Link: https://patchwork.kernel.org/patch/11806307/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that after replacing a device, if we run fstrim against the filesystem
we do not trim/discard allocated chunks in the new device. We verify that
allocated chunks in the new device were not trim/discarded by mounting the
new device only in degraded mode, as this is the easiest way to verify it.
This currently fails on btrfs (since kernel 5.2) and is fixed by a patch
that has the following subject:
"btrfs: fix filesystem corruption after a device replace"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs/198 is supposed to be a test for the patch
"btrfs: remove identified alien device in open_fs_devices" but this patch
was never merged in btrfs.
Remove the test from fstests' auto group, as it is constantly failing.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test an incremental send operation after doing a series of changes in a
tree such that one inode gets two hardlinks with names and locations
swapped with two other inodes that correspond to different directories,
and one of these directories is the parent of the other directory.
This currently fails on btrfs, the receive of the incremental send stream
fails. This is fixed by a patchset for btrfs which has two patches with the
following subjects:
"btrfs: send, orphanize first all conflicting inodes when processing references"
"btrfs: send, recompute reference path after orphanization of a directory"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation emits the correct path for link
and rename operation after swapping the names and locations of several
inodes in a way that creates a nasty dependency of rename and link
operations. Notably one file has its name and location swapped with a
directory for which it used to have a directory entry in it.
This test currently fails but a kernel patch for it exists and has the
following subject:
"btrfs: send, orphanize first all conflicting inodes when processing references"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
fstests only supports Linux, so get rid of this unnecessary predicate.
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>
This new test will apply different mount points and check if they
were applied by reading /proc/self/mounts. Almost all available
btrfs options are tested here, leaving only device=, which is tested
in btrfs/125 and space_cache, tested in btrfs/131.
This test does not apply any workload after the fs is mounted, just
checks is the option was set/unset correctly.
Kernel with the following patch should pass the test:
btrfs: reset compression level for lzo on remount
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The btrfs/154 testcase fails if the kernel patch "btrfs: handle
dynamically reappearing missing device" isn't applied, but this patch was
never merged into the upstream kernel.
Delete the test so we have one less testcase that will always fail.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Nikolay Borisov
Qu Wenruo
Filipe Manana
ethanwu
Josef Bacik
Anand Jain
Sidong Yang
Johannes Thumshirn
Darrick J. Wong
Marcos Paulo de Souza