This test case, btrfs/112, tests that some clone operations that have a
range covering inline extents fail with either -EOPNOTSUPP or -EINVAL.
These cases were unsupported on btrfs because they used to lead to file
corruptions and were not trivial to implement.
But there's now a patchset that adds support for them, and the relevant
patch of that patchset has the following subject:
"Btrfs: implement full reflink support for inline extents"
So just remove these tests from test case btrfs/112, since this test
case is about testing only the unsupported reflink operations. A new
test case that verifies that these cases now work, as long as some other
new cases, will follow in another patch.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A bug in file cloning/reflinking was recently found that afftected both
Btrfs and XFS, which was caused by allowing the cloning of an eof block
into the middle of a file when the eof is not aligned to the filesystem's
block size.
The fix consists of returning the errno -EINVAL to user space when the
arguments passed to the system call lead to the scenario of data
corruption. However this overlaps with some cases where the system call,
in Btrfs, returned -EOPNOTSUPP, which means we are trying to reflink
inline extents. That is unsupported in Btrfs due to the huge complexity
of supporting it (due to copying and trimming inline extents, deal with
eventual compression, etc).
We have a few btrfs test cases that verify that attempts to clone inline
extents result in a failure, and are currently expecting an -EINVAL error
message from the output of the cloner program. So create a filter that
converts error messages related to the -EOPNOTSUPP error to messages
related to the -EINVAL error, so that the test can run both on patched
and non-patched linux kernels.
The corresponding btrfs patch for the linux kernel is titled:
"Btrfs: fix data corruption due to cloning of eof block"
And the VFS change that introduces the -EINVAL error return was introduced
by the following linux kernel commit (landed in 4.20-rc1):
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
The btrfs patch is not yet in Linus' tree (it was submitted around the
same time as this change) and the VFS change was introduced in 4.10-rc1.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The check script requires that it be run as root, so adding
individualized checks for this in each teat is not needed.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I forgot to add the requirement for the xfs_io command "falloc", which
the test makes use of. Also fixed a weird indentation (mix of spaces
and tabs) for one line of a comment.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.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>
Filipe Manana
Dave Chinner
Theodore Ts'o