Regression test for btrfs ioctl clone operation + fsync + log
recovery. The issue was that doing an fsync after cloning into
a file didn't gave any persistence guarantees as it should.
What happened was that the in memory metadata (extent maps)
weren't updated, which made the fsync code not able to detect
that file data has been changed and must be persisted to the
log.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: make fsync work after cloning into a file
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 ioctl clone operation when the source range
contains hole(s) and the FS has the NO_HOLES feature enabled (file holes
don't need file extent items in the btree to represent them).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix clone to deal with holes when NO_HOLES feature is enabled
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 difference
between the snapshots used by the incremental send consists of one of
these cases:
1) First snapshot has a directory with name X and in the second snapshot
that directory doesn't exist anymore but a subvolume/snapshot with
the same name (X) exists;
2) First snapshot has a subvolume/snapshot with name X and in the second
snapshot that subvolume/snapshot doesn't exist anymore (might have been
replaced by a directory with the same name or not).
This issue is fixed by the following linux kernel btrfs patches:
Btrfs: send, don't error in the presence of subvols/snapshots
Btrfs: set dead flag on the right root when destroying snapshot
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>
Verify that btrfs send is able to replicate xattrs larger than
PATH_MAX. This is possible if the b+tree leaf size is larger
than 4Kb (mkfs.btrfs's default is max(16Kb, PAGE_SIZE) as of
btrfs-progs v3.12, and max(4Kb, PAGE_SIZE in older versions).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, use the right limits for xattr names and values
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 is a test to verify that the btrfs ioctl clone operation is
able to clone extents of a file to different positions of the file,
that is, the source and target files are the same. Existing tests
only cover the case where the source and target files are different.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
So that the same check (btrfs cloner program presence) can be reused
by other tests.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
Number of helpers for checking xfs_io functionality is slowly
growing. But it's as easy to simply use _require_xfs_io_command()
directly and just specify the command we want to check. It will also
avoid the need to create helper every time we need to check a new
command in xfs_io.
Remove all the helpers and use _require_xfs_io_command() in the
tests.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Files that consist of an inline extent, have the corresponding
data in the filesystem btree and not on a dedicated extent. For
such extents filefrag (fiemap) will report a physical location
of 0 for that extent and set the 'inline' flag.
The btrfs inspect-internal logical-resolve command will cause a
lookup in the extent tree for the extent address we give it as
an argument, which fails with errno ENOENT if it is 0.
This error didn't happen always, as the test uses fsstress to
generate a random filesystem, which needed to generate at least
one file that could be inlined (content less than 4018 bytes).
Example, taken from results/btrfs/004.full:
# filefrag -v /home/fdmanana/btrfs-tests/scratch_1/snap1/p0/de/d1b/dcb/fb1
Filesystem type is: 9123683e
File size of /home/fdmanana/btrfs-tests/scratch_1/snap1/p0/de/d1b/dcb/fb1 is 3860 (1 block of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 4095: 0.. 4095: 4096: not_aligned,inline,eof
1: 280.. 344: 35190.. 35254: 65: 1: eof
/home/fdmanana/btrfs-tests/scratch_1/snap1/p0/de/d1b/dcb/fb1: 2 extents found
after filter: 0#0#0 0#0#0
# stat -c %i /home/fdmanana/btrfs-tests/scratch_1/snap1/p0/de/d1b/dcb/fb1
403
# /home/fdmanana/git/hub/btrfs-progs/btrfs inspect-internal logical-resolve -P 0 /home/fdmanana/btrfs-tests/scratch_1
ioctl ret=-1, error: No such file or directory
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
If the file consists of a single block, then filefrag mentions
'1 block of ...', and the filter expected 'blocks of ...'.
Example:
$ echo qwerty > foobar
$ filefrag -v foobar
Filesystem type is: ef53
File size of foobar is 7 (1 block of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 0: 0.. 0: 1: unknown,delalloc,eof
foobar: 1 extent found
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 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>
As recently suggested by Dave Chinner, make use of the new function
named _run_btrfs_util_prog() to run the btrfs util program.
Filipe David Borba Manana have cleaned up btrfs/030 and btrfs/034.
I have done the same for the rest ones.
Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Also exported the variable "here" from the main control script, to avoid
repeating its declaration in every single testcase file. Also removed the
declaration of "here" from btrfs test cases that require the fssum program
only. Removing it from all other test cases will be a separate change.
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>
As recently suggested by Dave Chinner, make use of the new function
named _run_btrfs_util_prog() to run the btrfs util program, and stop
using run_check for running xfs_io - instead filter xfs_io's output
and add it to the golden output.
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 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>
Filipe David Borba Manana
Wang Shilong
Lukas Czerner
ZhangZhen