Move the cp --reflink tests from btrfs/ to generic/ since xfs now
supports that ioctl.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that truncating a file that consists of a compressed and inlined extent
to a smaller size and then cloning it into another file is not possible and
does not result in leaking stale data (data past the truncation offset) nor
losing data in the clone operation's destination file.
This btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: fix truncation of compressed and inlined extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test several cases of cloning inline extents that used to lead to file
corruption or data loss.
These file corruption and data loss cases are fixed by the linux kernel
patch titled:
"Btrfs: fix file corruption and data loss after cloning inline extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that sending a snapshot received from a different filesystem is
possible for both full and incremental send operations.
This used to work until the linux kernel release 4.2, but a commit [1] in
that release introduced a regression which did not allow this anymore.
The regression is fixed by the linux kernel patch titled:
"btrfs: fix resending received snapshot with parent"
[1] 37b8d27de5d0 ("Btrfs: use received_uuid of parent during send")
Cc: Josef Bacik <jbacik@fb.com>
Cc: Robin Ruede <rruede+git@gmail.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that sending and receiving snapshots across different filesystems
works for full and incremental send operations.
This used to fail before the linux kernel release 4.2. The linux kernel
commit that fixed this issue was the following:
37b8d27de5d0 ("Btrfs: use received_uuid of parent during send")
Cc: Josef Bacik <jbacik@fb.com>
Cc: Robin Ruede <rruede+git@gmail.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that a send operation works correctly with reflinked files (cloned
extents which multiple files point to) that have compressed extents.
This used to fail on btrfs, resulting in different file digests after
receiving the send stream, and got fixed by the linux kernel patch
titled:
"Btrfs: send, fix file corruption due to incorrect cloning operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that a send operation works correctly with reflinked files (cloned
extents which multiple files point to).
The btrfs issue was fixed by the linux kernel patch titled:
"Btrfs: send, fix file corruption due to incorrect cloning operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Even the fallocate range doesn't cover the last page of a file, btrfs
will still re-truncate the last page.
Such behavior is completely duplicated and unneeded, and fixed by the
following kernel patch:
btrfs: Avoid truncate tailing page if fallocate range doesn't exceed
inode size
Add this test case to check that malfunction.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for file read corruption when using compressed extents
that represent file ranges with a length that is a multiple of 16 pages
and that are shared by multiple consecutive ranges of the same file.
This is similar to the test added in commit 694db0c050 ("btrfs: read
corruption of compressed extents"), but tests the special case where the
extent's uncompressed length is a multiple of 16 pages. The first btrfs
fix, tested by the test added in the commit mentioned before, failed to
address this special case.
This btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: update fix for read corruption of compressed and shared extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that an incremental send works after a file from the parent snapshot
gets replaced in the send snapshot by another one at the same exact
location, with the same name and with the same inode number.
This test used to fail after the linux kernel commit 8b191a684968
("Btrfs: incremental send, check if orphanized dir inode needs delayed
rename") and it's fixed by patch titled:
"Btrfs: send, fix corner case for reference overwrite detection"
Signed-off-by: Martin Raiber <martin@urbackup.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test btrfs quota group consistency operations during snapshot
delete. Btrfs has had long standing issues with drop snapshot
failing to properly account for quota groups. This test crafts
several snapshot trees with shared and exclusive elements. One of
the trees is removed and then quota group consistency is checked.
This issue is fixed by the following linux kernel patches:
Btrfs: use btrfs_get_fs_root in resolve_indirect_ref
Btrfs: keep dropped roots in cache until transaciton commit
btrfs: qgroup: account shared subtree during snapshot delete
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for file read corruption when using compressed extents
that are shared by multiple consecutive ranges of the same file.
The btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: fix read corruption of compressed and shared extents"
Without the corresponding fix the test fails because the second time it
reads the test files it gets different data (some pages are incorrectly
filled with zeroes) from the data it wrote before doing a clean ummount.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for an ENOSPC issue when attempting to write to a file in
a filesystem without any data block groups allocated.
The btrfs issue is fixed by the linux kernel patch titled
"Btrfs: don't initialize a space info as full to prevent ENOSPC" and the
regression was introduced by the patch titled
"Btrfs: fix block group ->space_info null pointer dereference".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case tests if the device delete works with
the failed (EIO) source device. EIO errors are achieved
usign the DM device.
This test would need following btrfs-progs and btrfs
kernel patch
btrfs-progs: device delete to accept devid
Btrfs: device delete by devid
However when btrfs-progs patch is not found this test will
not run, and when kernel patch is not found btrfs-progs
will fail gracefully and thus the test script.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case will test to confirm the replace works with
the failed (EIO) replacing source device. EIO condition is
achieved using the DM device.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs qgroup reserve codes lacks check for rewrite dirty page, causing
every write, even rewriting a uncommitted dirty page, to reserve space.
But only written data will free the reserved space, causing reserved
space leaking.
The bug exists almost from the beginning of btrfs qgroup codes, but
nobody found it.
For example:
1)Write [0, 12K) into file A
reserve 12K space
File A:
0 4K 8K 12K
|<--------dirty-------->|
reserved: 12K
2)Write [0,4K) into file A
0 4K 8K 12K
|<--------dirty-------->|
reserved: 16K <<< Should be 12K
3) Commit transaction
Dirty pages [0,12) written to disk.
Free 12K reserved space.
reserved: 4K <<< Should be 0
This testcase will test such problem.
Kernel fix will need some huge change, so won't be soon.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Test that if we fsync a file that got one extent partially cloned into a
lower file offset, after a power failure our file has the same content it
had before the power failure and after the extent cloning operation.
This test is motivated by an issue found in btrfs that is fixed by the
linux kernel patch titled:
"Btrfs: fix file read corruption after extent cloning and fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that an incremental send works after a file gets one of its extents
cloned/deduplicated into lower file offsets.
This is a regression test for the problem fixed by the linux kernel patch
titled:
"Btrfs: teach backref walking about backrefs with underflowed
offset values"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This tests that we can not clone an inline extent into a non-zero file
offset. Inline extents at non-zero offsets is something btrfs is not
prepared for and results in all sorts of corruption and crashes on
future IO operations, such as the following BUG_ON() triggered by the
last write operation done by this test:
[152154.035903] ------------[ cut here ]------------
[152154.036424] kernel BUG at mm/page-writeback.c:2286!
[152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
(...)
[152154.036424] RIP: 0010:[<ffffffff8111a9d5>] [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
(...)
[152154.036424] Call Trace:
[152154.036424] [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs]
[152154.036424] [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs]
[152154.036424] [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs]
[152154.036424] [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs]
[152154.036424] [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs]
[152154.036424] [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5
[152154.036424] [<ffffffff81165f89>] vfs_write+0xa0/0xe4
[152154.036424] [<ffffffff81166855>] SyS_pwrite64+0x64/0x82
[152154.036424] [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
(...)
[152154.242621] ---[ end trace e3d3376b23a57041 ]---
This issue is addressed by the following linux kernel patch for btrfs:
"Btrfs: fix file corruption after cloning inline extents".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for adding and dropping an equal number of references
for file extents. Verify that if we drop N references for a file extent
and we add too N new references for that same file extent in the same
transaction, running the delayed references (which always happens at
transaction commit time) does not fail.
The regression was introduced in the 4.2-rc1 Linux kernel and fixed by
the patch titled: "Btrfs: fix order by which delayed references are run".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add a regression test for a problem where attempting to delete the
default subvolume would fail (as expected), but not until after all
submounts under the subvolume were unmounted.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that an incremental send issues valid clone operations for
compressed file extents.
For some compressed extents, namely those referred by a file extent item
with a non-zero data offset, btrfs could issue a clone operation in the
send stream with an offset and length pair that were not entirely
contained in the source file's range, causing the receiving side to get
-EINVAL errors from the clone ioctl when attempting to perform the clone
operations.
This issue was fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, fix clone operations for compressed extents
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test btrfs file range cloning with the same file as a source and
destination.
This tests a specific scenario where the extent layout of the file
confused the clone ioctl implementation making it return -EEXIST to
userspace. This issue was fixed by the following linux kernel patch:
Btrfs: fix range cloning when same inode used as source and destination
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test btrfs incremental send after renaming and moving directories around in a
way that ends up making a directory have different dentries with the same name
but pointing to different inodes in the parent and send snapshots, and also
inverting the ancestor-descendent relationship between one of those inodes and
some other inode.
Cases like this made an incremental send enter an infinite lopp when building
path strings, leading to -ENOMEM errors when the path string reached a length
of PATH_MAX.
This issue was fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, check if orphanized dir inode needs delayed rename
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
[Problem]
Since commit fcebe4562dec83b3f8d308 ("Btrfs: rework qgroup accounting"),
quota data update is delayed after delayed_ref calculation, and lacks
correct protection to detect root reference which shouldn't be counted
in current sequence number but already written into extent backref.
This makes exclusive reference not decreased correctly and give incorrect
result.
[Test procedure]
1. Create a btrfs with 3 subvolumes, quota enabled and rescanned.
2. Create a file in 1st subvolume
3. Clone the file to 2nd and 3rd subvolume
4. Sync the fs to reflect the changes in qgroup.
5. Check the qgroup data
[Expected result]
None of the subvolume has exclusive reference to the file.
[Actual result]
The first subvolume still have exclusive reference to the file.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Darrick J. Wong
Filipe Manana
Qu Wenruo
Mark Fasheh
Anand Jain
Omar Sandoval