fstests.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents
@ 2020-02-19 14:06 fdmanana
  2020-02-20 15:31 ` Josef Bacik
  0 siblings, 1 reply; 2+ messages in thread
From: fdmanana @ 2020-02-19 14:06 UTC (permalink / raw)
  To: fstests; +Cc: linux-btrfs, Filipe Manana

From: Filipe Manana <fdmanana@suse.com>

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>
---
 tests/btrfs/112     | 31 -----------------------------
 tests/btrfs/112.out | 48 ---------------------------------------------
 2 files changed, 79 deletions(-)

diff --git a/tests/btrfs/112 b/tests/btrfs/112
index e4e9d322..13c19863 100755
--- a/tests/btrfs/112
+++ b/tests/btrfs/112
@@ -83,22 +83,6 @@ test_cloning_inline_extents()
 	od -t x1 $SCRATCH_MNT/foo2
 	$XFS_IO_PROG -c "pwrite -S 0xee 0 90" $SCRATCH_MNT/foo2 | _filter_xfs_io
 
-	# Test cloning the inline extent against a file which has a size of zero
-	# but has a prealloc extent. It should not be possible as well to clone
-	# the inline extent from file bar into this file.
-	$XFS_IO_PROG -f -c "falloc -k 0 1M" $SCRATCH_MNT/foo3 | _filter_xfs_io
-	$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo3 \
-		| _filter_btrfs_cloner_error
-
-	# Doing IO against any range in the first 4K of the file should work.
-	# Due to a past clone ioctl bug which allowed cloning the inline extent,
-	# these operations resulted in EIO errors.
-	echo "First 50 bytes of foo3 after clone operation:"
-	# Should not be able to read any bytes, file has 0 bytes i_size (the
-	# clone operation failed and did not modify our file).
-	od -t x1 $SCRATCH_MNT/foo3
-	$XFS_IO_PROG -c "pwrite -S 0xff 0 90" $SCRATCH_MNT/foo3 | _filter_xfs_io
-
 	# Test cloning the inline extent against a file which consists of a
 	# single inline extent that has a size not greater than the size of
 	# bar's inline extent (40 < 50).
@@ -157,21 +141,6 @@ test_cloning_inline_extents()
 	# Must have a size of 50 bytes, with all bytes having a value of 0xbb.
 	od -t x1 $SCRATCH_MNT/foo7
 
-	# Test cloning the inline extent against a file which has a size not
-	# greater than the size of bar's inline extent (20 < 50) but has
-	# a prealloc extent that goes beyond the file's size. It should not be
-	# possible to clone the inline extent from bar into this file.
-	$XFS_IO_PROG -f -c "falloc -k 0 1M" \
-			-c "pwrite -S 0x88 0 20" \
-			$SCRATCH_MNT/foo8 | _filter_xfs_io
-	$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo8 \
-		| _filter_btrfs_cloner_error
-
-	echo "File foo8 data after clone operation:"
-	# Must have a size of 20 bytes, with all bytes having a value of 0x88
-	# (the clone operation did not modify our file).
-	od -t x1 $SCRATCH_MNT/foo8
-
 	_scratch_unmount
 }
 
diff --git a/tests/btrfs/112.out b/tests/btrfs/112.out
index 3a95e14d..8c26d758 100644
--- a/tests/btrfs/112.out
+++ b/tests/btrfs/112.out
@@ -24,11 +24,6 @@ File foo2 data after clone operation:
 0040000
 wrote 90/90 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-First 50 bytes of foo3 after clone operation:
-0000000
-wrote 90/90 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 wrote 40/40 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 File foo4 data after clone operation:
@@ -56,13 +51,6 @@ File foo7 data after clone operation:
 *
 0000060 bb bb
 0000062
-wrote 20/20 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-File foo8 data after clone operation:
-0000000 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88
-0000020 88 88 88 88
-0000024
 
 Testing with compression and without the no-holes feature...
 
@@ -88,11 +76,6 @@ File foo2 data after clone operation:
 0040000
 wrote 90/90 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-First 50 bytes of foo3 after clone operation:
-0000000
-wrote 90/90 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 wrote 40/40 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 File foo4 data after clone operation:
@@ -120,13 +103,6 @@ File foo7 data after clone operation:
 *
 0000060 bb bb
 0000062
-wrote 20/20 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-File foo8 data after clone operation:
-0000000 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88
-0000020 88 88 88 88
-0000024
 
 Testing without compression and with the no-holes feature...
 
@@ -152,11 +128,6 @@ File foo2 data after clone operation:
 0040000
 wrote 90/90 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-First 50 bytes of foo3 after clone operation:
-0000000
-wrote 90/90 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 wrote 40/40 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 File foo4 data after clone operation:
@@ -184,13 +155,6 @@ File foo7 data after clone operation:
 *
 0000060 bb bb
 0000062
-wrote 20/20 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-File foo8 data after clone operation:
-0000000 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88
-0000020 88 88 88 88
-0000024
 
 Testing with compression and with the no-holes feature...
 
@@ -216,11 +180,6 @@ File foo2 data after clone operation:
 0040000
 wrote 90/90 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-First 50 bytes of foo3 after clone operation:
-0000000
-wrote 90/90 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 wrote 40/40 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 File foo4 data after clone operation:
@@ -248,10 +207,3 @@ File foo7 data after clone operation:
 *
 0000060 bb bb
 0000062
-wrote 20/20 bytes at offset 0
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-clone failed: Invalid argument
-File foo8 data after clone operation:
-0000000 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88
-0000020 88 88 88 88
-0000024
-- 
2.25.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents
  2020-02-19 14:06 [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents fdmanana
@ 2020-02-20 15:31 ` Josef Bacik
  0 siblings, 0 replies; 2+ messages in thread
From: Josef Bacik @ 2020-02-20 15:31 UTC (permalink / raw)
  To: fdmanana, fstests; +Cc: linux-btrfs, Filipe Manana

On 2/19/20 9:06 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> 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>

Thanks,

Josef

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-02-20 15:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-19 14:06 [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents fdmanana
2020-02-20 15:31 ` Josef Bacik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).