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>
The return value should always be 0 if no problem happens, but
"btrfs filesystem show" executed on umounted device will always return 1
even there is no problem.
This testcase just checks it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that btrfs' transaction abortion does not corrupt a filesystem
mounted with -o discard nor allows a subsequent fstrim to corrupt the
filesystem (regardless of being mounted with or without -o discard).
This issue was fixed by the following linux kernel patch:
Btrfs: fix fs corruption on transaction abort if device supports discard
(commit 678886bdc6378c1cbd5072da2c5a3035000214e3)
Without the corresponding btrfs fix the fs becomes unmountable and fails
like this:
$ ./check btrfs/089
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian3 3.19.0-btrfs-next-7+
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/089 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/089.out.bad)
--- tests/btrfs/089.out 2015-04-03 19:29:42.969594083 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/089.out.bad 2015-04-03 19:42:37.419181019 +0100
@@ -3,7 +3,10 @@
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 1048576/1048576 bytes at offset 524288
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+mount: wrong fs type, bad option, bad superblock on /dev/sdc,
+ missing codepage or helper program, or other error
+ In some cases useful info is found in syslog - try
+ dmesg | tail or so
...
(Run 'diff -u tests/btrfs/089.out /home/fdmanana/git/hub/xfstests/results//btrfs/089.out.bad' to see the entire diff)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent (see /home/fdmanana/git/hub/xfstests/results//btrfs/089.full)
Ran: btrfs/089
Failures: btrfs/089
Failed 1 of 1 tests
$ cat /home/fdmanana/git/hub/xfstests/results//btrfs/089.full
Performing full device TRIM (100.00GiB) ...
touch: cannot touch '/home/fdmanana/btrfs-tests/scratch_1/abc': Read-only file system
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
read block failed check_tree_block
Couldn't read tree root
Couldn't open file system
(...)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test a very complex scenario for a btrfs incremental send operation where a
large directory hierarchy had many subtrees moved between parent directories,
preserving the names of some directories and inverting the parent-child
relationship between some directories (a child in the parent snapshot became
a parent, in the send snapshot, of the directory that is its parent in the
parent snapshot).
This test made the incremental send fail with -ENOMEM because it entered an
infinite loop when building path strings that are used as operands of the
rename operations issued in the send stream.
This issue was fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, don't delay directory renames unnecessarily
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test cloning a file range with a length of zero into a destination offset
greater than zero.
This made btrfs create an extent state record with a start offset greater than
the end offset, resulting in chaos such as an infinite loop when evicting an
inode.
This issue was fixed by the following linux kernel patch:
Btrfs: fix inode eviction infinite loop after cloning into it
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test tests three conditions where orphan items need to be
cleaned up:
1) Default subvolume is fs tree root (mkfs default)
2) Default subvolume has been set explicitly to another subvolumei
(set-default)
3) Looking up a subvolume during a traversal
In the kernel, these three cases use separate mechanisms to look up
the subvolumes. There was a bug in the kernel where case #2 wasn't
getting handled and so orphan items would never be cleaned up if the
default subvolume was explicitly set. This issue was fixed with the
upstream commit: btrfs: cleanup orphans while looking up default
subvolume.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test for incremental send where the difference between the parent and
send snapshots is that for a subtree with the same path in both snapshots
(p1/p2), the root directories were swapped.
This issue was fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, clear name from cache after orphanization
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test for incremental send where the difference between the parent and
child snapshots is that a directory A was renamed and a directory B was
renamed to the name directory A had before (in the parent snapshot),
but directory A's rename must happen before some other directory C is
renamed.
This issue was fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, don't rename a directory too soon
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs issue of resizing 'thread_pool' when
remount the fs.
This regression was introduced by the following linux kernel commit:
btrfs: Added btrfs_workqueue_struct implemented ordered
execution based on kernel workqueue
08a9ff3264181986d1d692a4e6fce3669700c9f8
And it was fixed by the following linux kernel commit:
btrfs: fix crash in remount(thread_pool=) case
800ee2247f483b6d05ed47ef3bbc90b56451746c
Signed-off-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs clone ioctl issue where races between
a clone operation and concurrent target file reads would result in
leaving stale data in the page cache. After the clone operation
finished, reading from the clone target file would return the old
and no longer valid data. This affected only buffered reads (i.e.
didn't affect direct IO reads).
This issue was fixed by the following linux kernel patch:
Btrfs: ensure readers see new data after a clone operation
(commit c125b8bff1d9f6c8c91ce4eb8bd5616058c7d510)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Mark Fasheh
Filipe Manana
Anand Jain
Qu Wenruo
Omar Sandoval
Jeff Mahoney
Xing Gu
Liu Bo