generic/304: only dedupe the last 64k of the single byte file

Commit Message

Darrick J. Wong April 17, 2018, 5:20 a.m. UTC

From: Darrick J. Wong <[e-mail]>

Commit 1ddae54555b62 ("common/rc: add missing 'local' keywords") exposed
a long-hidden bug in generic/304 -- previously we'd set len to 8EiB, but
_pwrite_byte reset it to 1 because the helper clumsily polluted the
caller's variable namespace.  Now that's fixed, but we send an 8EiB
dedupe request to the kernel, which on XFS locks up the kernel while
doing this.  The point of this test is to demonstrate that one cannot
dedupe the last byte of a (2^63-1) byte file (that's the way the
interface has behaved historically), so start at 64k below that instead
of offset zero.

Signed-off-by: Darrick J. Wong <[e-mail]>
---
 tests/generic/304 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/tests/generic/304 b/tests/generic/304
index 6c36a68..ff8ddf8 100755
--- a/tests/generic/304
+++ b/tests/generic/304
@@ -63,7 +63,7 @@  _pwrite_byte 0x61 $bigoff 1 $testdir/file3 >> $seqres.full
 _pwrite_byte 0x61 1048575 1 $testdir/file2 >> $seqres.full
 
 echo "Dedupe large single byte file"
-_dedupe_range $testdir/file1 0 $testdir/file3 0 $len \
+_dedupe_range $testdir/file1 $bigoff_64k $testdir/file3 $bigoff_64k 65536 \
 	2>&1 >> $seqres.full | _filter_dedupe_error
 
 echo "Dedupe large empty file"