Regression test for btrfs send where long paths (exceeding 230 characters)
made send produce paths with random characters from a memory buffer returned
by kmalloc, as send forgot to populate the new buffer with the path string.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, fix corrupted path strings for long paths
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression for btrfs send when an inode only has extended references
associated to it (no regular references present). This used to cause
incorrect access to a b+tree leaf, where an extended reference item
was accessed as if it were a regular reference item, causing unexpected
and unpredictable behaviour such as producing a random/weird path string
or a crash.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, fix incorrect ref access when using extrefs
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch adds a regression test to verify btrfs can not
reuse inode id until we have committed transaction. Which was
addressed by the following kernel patch:
Btrfs: fix inode cache vs tree log
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case verifies the btrfs properties feature, a new feature
introduced in the linux kernel version 3.14.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test verifies that after an incremental btrfs send the
replicated file has the same exact hole and data structure as in
the origin filesystem. This didn't use to be the case before the
send stream version 2 - holes were sent as write operations of 0
valued bytes instead of punching holes with the fallocate system
call, and pre-allocated extents were sent as well as write
operations of 0 valued bytes instead of intructions for the
receiver to use the fallocate system call.
It also checks that prealloc extents that lie beyond the file's
size are replicated by an incremental send.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for the btrfs incremental send feature, where the kernel
would incorrectly consider a range of a file as a hole and send a stream
of 0 bytes to the destination (send stream) that would overwrite the
corresponding file region.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, fix data corruption due to incorrect hole detection
(https://patchwork.kernel.org/patch/3910081/)
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue where the kernel failed
to build paths strings. This resulted either in sending a wrong path string
to the send stream or entering an infinite loop when building it.
This happened in the following scenarios:
1) A directory was made a child of another directory which has a lower inode
number and has a pending move/rename operation or there's some non-direct
ancestor directory with a higher inode number that was renamed/moved too.
This made the incremental send code go into an infinite loop when building
a path string;
2) A directory was made a child of another directory which has a higher inode
number, but the new parent wasn't moved nor renamed. Instead some other
ancestor higher in the hierarchy, with an higher inode number too, was
moved/renamed too. This made the incremental send code go into an infinite
loop when building a path string;
3) An orphan directory is created and at least one of its non-immediate
descendent directories have a pending move/rename operation. This made
an incremental send issue to the send stream an invalid path string that
didn't account for the orphan ancestor directory.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue where invalid paths for
utimes, chown and chmod operations were sent to the send stream, causing
btrfs receive to fail.
If a directory had a move/rename operation delayed, and none of its parent
directories, except for the immediate one, had delayed move/rename operations,
after processing the directory's references, the incremental send code would
issue invalid paths for utimes, chown and chmod operations.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send issuing outdated paths for utimes, chown and chmod
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs incremental send issue where a rmdir instruction
is sent against an orphan directory inode which is not empty yet, causing
btrfs receive to fail when it attempts to remove the directory.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send attempting to rmdir non-empty directories
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add missing test for btrfs quota groups feature,test idea is to create
a parent qgroup that groups some subvolume groups, we try to write
some data into every subvolume and then check if we exceed parent
qgroup's limit size.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is a regression test to verify that the restore feature of btrfs-progs
is able to correctly recover files that have compressed extents, specially when
the respective file extent items have a non-zero data offset field.
This issue is fixed by the following btrfs-progs patch:
Btrfs-progs: fix restore dealing with compressed extents
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs incremental send issue where an rmdir
instruction was sent multiple times for the same target directory.
The number of times depended on the number of hardlinks against
the same inode inside the target directory. That inode must have
had the highest number of all the inodes that were children of the
directory. This made the btrfs receive command fail immediately once
it received the second rmdir instruction.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, don't send rmdir for same target multiple times
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue related to
renaming of directories. If at the time of the initial send we have
a directory that is a child of a directory with a higher inode
number, and then later after the initial full send we rename both
the child and parent directories, but without moving any of them, a
subsequent incremental send would produce a rename instruction for
the child directory that pointed to an invalid path. This made the
btrfs receive operation fail.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, fix invalid path after dir rename
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test for a btrfs incremental send issue where we end up sending a
wrong section of data from a file extent if the corresponding file
extent is compressed and the respective file extent item has a non
zero data offset.
Fixed by the following linux kernel btrfs patch:
Btrfs: use right clone root offset for compressed extents
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test for a btrfs data corruption when using compressed
files/extents. Under certain cases, it was possible for reads to
return random data (content from a previously used page) instead of
zeroes. This also caused partial updates to those regions that were
supposed to be filled with zeroes to save random (and invalid) data
into the file extents.
This is fixed by the commit for the linux kernel titled:
Btrfs: fix data corruption when reading/updating compressed extents
(https://patchwork.kernel.org/patch/3610391/)
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs would fail to send if snapshot run concurrently, this test is to make
sure we have fixed the bug.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test uses the newly added cloner binary to dispatch full file and
range specific clone (reflink) requests.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs incremental send had an issue where it would detect a non-existent
file hole and then overwrite the file section that hole covers with zeroes,
overriding file data that it shouldn't.
The respective btrfs kernel patch that fixed this issue is titled:
Btrfs: fix send file hole detection leading to data corruption
(https://patchwork.kernel.org/patch/3544831/)
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs send/scrub/defrag/qgroup need to walk backrefs,this test
is to make sure iterating backrefs with ulist is working and don't
cause a kernel panic here.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs would get a transaction abortion when remounting RW to RO with
flushoncommit enabled. This test is to check if bug still exists.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This testscript creates reflinks to files on different subvolumes,
overwrites the original files and reflinks, and moves reflinked files
between subvolumes.
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs' incremental send feature:
1) Create several nested directories;
2) Create a read only snapshot;
3) Change the parentship of some of the deepest directories in a reverse
way, so that parents become children and children become parents;
4) Create another read only snapshot and use it for an incremental send
relative to the first snapshot.
At step 4 btrfs' send entered an infinite loop, increasing the memory it
used while building path strings until a krealloc was unable to allocate
more memory, which caused a warning dump in dmesg.
The following linux kernel patch fixes this issue.
Btrfs: fix infinite path build loops in incremental send
(https://patchwork.kernel.org/patch/3522361/)
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check if creating a sparse copy ("reflink") of a file on btrfs
expectedly fails when it's done between different filesystems or
different mount points of the same filesystem.
For both situations, these actions are executed:
- Copy a file with the reflink=auto option.
A normal copy should be created.
- Copy a file with the reflink=always option. Should result in
error.
[sandeen: mostly cosmetic changes]
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Moving and deleting cloned ("reflinked") files on btrfs:
- Create a file and a reflink
- Move both to a directory
- Delete the original (moved) file, check that the copy still exists.
[sandeen: mostly cosmetic changes]
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Tests file clone functionality of btrfs ("reflinks") on directory trees.
- Create directory and subdirectory, each having one file
- Create 2 recursive reflinked copies of the tree
- Modify the original files
- Modify one of the copies
[sandeen: mostly cosmetic changes]
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Filipe David Borba Manana
Wang Shilong
David Disseldorp
Koen De Wit