Test a scenario where we do several partial writes into multiple
preallocated extents across two transactions and with several fsyncs
in between. The goal is to check that the fsyncs succeed.
Currently the last fsync fails with an -EIO error, and it aborts the
current transaction. This issue is fixed by a patch with the following
subject:
"btrfs: fix fsync failure and transaction abort after writes to prealloc extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test a particular scenario where we fsync a directory, then move one of
its children directories into another directory and then finally sync the
log trees by fsyncing any other inode. We want to check that after a power
failure we are able to mount the filesystem and that the moved directory
exists only as a child of the directory we moved it into.
This currently fails on a 5.12 kernel (and 5.13-rc1) but is fixed by a
patch with the following subject:
"btrfs: fix removed dentries still existing after log is synced"
The failure is due to ending up with a directory that has 2 hard links
(two parent directories) as soon as the log replay procedure finishes,
which causes the tree checker to detect the issue and cause the mount
operation to fail with -EIO.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a test for commit 18bb8bbf13c1 ("btrfs: zoned: automatically
reclaim zones").
This test creates a two file on a newly created FS in a way that
when we delete the first one, an auto reclaim process will be
triggered by the FS.
After the reclaim process, it verifies that the data was moved to
another zone and old zone was successfully reset.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test for fsync data loss after renaming a file or adding a hard link,
with a previous fsync of another file, as well as that mtime and ctime
are correct after a power failure. Test both with COW and NOCOW writes.
This currently fails differently on different kernels:
- For kernels older than 4.19 (<= 4.18) and kernels starting from 5.10,
the NOCOW tests are expected to fail very often on the mtime and ctime
checks.
The data loss check has slim chances of failing on a virtualized
environment, because the race that leads to the data loss is due to
the fsync() returning after writeback of the data finishes and
returning without issuing barriers (sending REQ_PREFLUSH to the
device), as explained in the test's comments.
For kernels between 4.19 (inclusive) and 5.9 (inclusive), it is not
expected to fail.
- For the btrfs integration branch (misc-next), and what is currently in
Linus' master branch (5.13 merge window changes), in addition to the
failures mentioned before, the test should fail very often on the data
loss and mtime/ctime checks for COW writes.
The issues are fixed by a patch for the kernel that has the following
subject:
"btrfs: fix race leading to unpersisted data and metadata on fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we set a capability on a file but not on the next files we
create, send/receive operations only apply the capability to the first
file, the one for which we have set a capability.
This is motivated by a regression that started to happen with kernel 5.8,
caused by an incompatibility between kernel commit 89efda52e6b693
("btrfs: send: emit file capabilities after chown") and a workaround for
send/receive added to btrfs-progs several years ago by btrfs-progs
commit 123a2a085027e ("btrfs-progs: receive: restore capabilities after
chown"). That workaround in btrfs-progs was added in btrfs-progs 4.1.
That kernel commit ended up fixing the bugs the btrfs-progs commit
targeted, as well as other bugs around btrfs send and capabilities.
However it did not play nice with the btrfs-progs workaround.
The kernel fix was backported to all stable kernels and the btrfs-progs
workaround was later removed from btrfs-progs by commit 81d8ea9346c6ee
("btrfs-progs: receive: remove workaround for setting capabilities"),
introduced in btrfs-progs 5.11.
The test currently fails on any environment using kernel 5.8+ and a
btrfs-progs version between 4.1 and 5.10. Updating btrfs-progs to
version 5.11 makes the test pass.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test cases where a direct IO write, with O_DSYNC, can not be done and has
to fallback to a buffered write.
This is motivated by the fact we don't have existing tests for these cases
and in fact we had a regression for one case in the 5.10 kernel. This was
the case when doing a direct IO write, with O_DSYNC, against a file offset
that is not aligned to the filesystem's block size, which resulted in
triggering an assertion failure when btrfs is built with assertions enabled
(CONFIG_BTRFS_ASSERT=y). One openSUSE Tumbleweed user hit this frequently
when using Docker and DB2.
The kernel commit in 5.10 that introduced the regression was commit
0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround")). In kernel 5.11 the
regression fixed, by pure chance, by commit ecfdc08b8cc65d ("btrfs: remove
dio iomap DSYNC workaround"). Since the commit that fixed the bug in 5.11
was dependent on a large patchset, a special and simple fix was added to
the stable kernel 5.10.18 by commit a6703c71153438 ("btrfs: fix crash after
non-aligned direct IO write with O_DSYNC").
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that subvolume deletion is resumed on RW mounts, that it is not
performed on RO mounts and that after remounting a filesystem from RO
to RW mode, it is also performed.
This triggers a regression introduced in kernel 5.11 which is fixed
by a patch that has the following subject:
"btrfs: fix subvolume/snapshot deletion not triggered on mount"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
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>
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>
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>
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>
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>
Filipe Manana
Anand Jain
Johannes Thumshirn
Nikolay Borisov
Qu Wenruo
ethanwu
Sidong Yang
Marcos Paulo de Souza