All of lore.kernel.org
 help / color / mirror / Atom feed
From: fdmanana@kernel.org
To: fstests@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org, Filipe Manana <fdmanana@suse.com>
Subject: [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents
Date: Wed, 19 Feb 2020 14:06:27 +0000	[thread overview]
Message-ID: <20200219140627.1641733-1-fdmanana@kernel.org> (raw)

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


             reply	other threads:[~2020-02-19 14:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 14:06 fdmanana [this message]
2020-02-20 15:31 ` [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents Josef Bacik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200219140627.1641733-1-fdmanana@kernel.org \
    --to=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.