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>
This is a test to check the behavior of the disk caching code inside
btrfs. It's a regression test for the patch
btrfs: allow single disk devices to mount with older generations
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for the issue fixed by
btrfs: init device stats for seed devices
We create a seed device, add a sprout device, and then check the device
stats after a remount to make sure it succeeds.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There is a bug in trim code which leads to fstrim accessing beyond
device boundary.
The test case will check if fstrim, then shrink, then fstrim, all of
them works without problem.
The fix is titled "btrfs: trim: fix underflow in trim length to prevent
access beyond device boundary".
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This patch ensures device corrupted counter is being modified when we try to
read broken data.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test exercises full send and incremental send operations for cases
where files have capabilities, ensuring the capabilities aren't lost in
the process.
There was a problem with kernel <=5.7 that was making capabilities
to be lost after a combination of full + incremental send. This
behavior was fixed by commit 89efda52e6b6 ("btrfs: send: emit file
capabilities after chown").
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test if canceling a running balance can cause later balance to dead
loop.
The fix is titled "btrfs: relocation: Clear the DEAD_RELOC_TREE bit for
orphan roots to prevent runaway balance".
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test if canceled balance could lead to root leakage.
If the kernel has CONFIG_BTRFS_DEBUG compiled, unmount time root leakge
check would detect it, and cause NULL pointer dereference as the pages
of the leaked root are already freed.
The fix is titled "btrfs: relocation: Fix reloc root leakage and the NULL
pointer reference caused by the leakage".
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 if we fsync a file with prealloc extents that start before and
after the file's size, we don't end up with missing parts of the extents
and implicit file holes after a power failure. Test both without and with
the NO_HOLES feature.
It is fixed commit f135cea30de5 ("btrfs: fix partial loss of
prealloc extent past i_size after 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 a new snapshot created with qgroup inherit passed should
mark qgroup numbers inconsistent.
Such inconsistent flag is required to show that we need a qgroup
rescan to make qgroup numbers correct again.
This is unavoidable since snapshot creation with qgroup inherit acts
as snapshot creation + qgroup relationship assign.
See btrfs(5) for why such operation needs qgroup rescan.
This test failed on current kernel, the fix is submitted to the btrfs
mail list titled:
"btrfs: qgroup: Mark qgroup inconsistent if we're inherting snapshot to a new qgroup"
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some tests exercise balance but are not included in the 'balance' group,
so just add them to that group.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test a scenario were we fsync a range of a file and have a power
failure. We want to check that after a power failure and mounting
the filesystem, we do not end up with a missing file extent
representing a hole. This applies only when not using the NO_HOLES
feature.
This currently fails on btrfs but it is fixed by a patch for the kernel
that has the following subject:
"Btrfs: fix missing file extent item for hole after ranged fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Now btrfs can delete subvolumes based in ther subvolume id. This
makes easy for the user willing to delete a subvolume that cannot be
accessed by the mount point, since btrfs allows to mount a specific
subvolume and hiding the other from the mount point.
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>
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>
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 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>
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>
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>
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>
Filipe Manana
Marcos Paulo de Souza
Johannes Thumshirn
Josef Bacik
Qu Wenruo
Anand Jain
Nikolay Borisov
Omar Sandoval
Theodore Ts'o