generic/564: fix copy_range -f availability test
authorEric Sandeen <sandeen@redhat.com>
Thu, 12 Sep 2019 16:15:49 +0000 (11:15 -0500)
committerEryu Guan <guaneryu@gmail.com>
Sun, 15 Sep 2019 04:29:10 +0000 (12:29 +0800)
generic/564 wants to test for copy_range -f, but as it's implemented
it calls copy_range with a length of zero which will silently return
success from the VFS (at least on some kernels) even if the underlying
fs doesn't support it.

So patch this up 2 ways; perform the test with an explicit length
so it's not a no-op, and go ahead test copy_range w/o -f in the test
first just to be on the safe side (and for clearer failure messages.)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
common/rc
tests/generic/564

index e0b087c10e8f1a0c5394dbb1a9423a032bef0bef..66c7fd4d7a6c4c09b6a7ab5a4f6f067d0ccf8cf7 100644 (file)
--- a/common/rc
+++ b/common/rc
@@ -2109,7 +2109,7 @@ _require_xfs_io_command()
                if [ "$param" == "-f" ]; then
                        # source file is the open destination file
                        testcopy=$testfile
-                       copy_opts="0 -d 4k"
+                       copy_opts="0 -d 4k -l 4k"
                fi
                $XFS_IO_PROG -F -f -c "pwrite 0 4k" $testfile > /dev/null 2>&1
                testio=`$XFS_IO_PROG -F -f -c "copy_range $param $copy_opts" $testcopy 2>&1`
index ee1786cc8d0abe129d35575bcf44a06dea0ac0cf..4958b3b5696ec0f167ef9c8c0638ebf1f769229f 100755 (executable)
@@ -49,6 +49,8 @@ _require_loop
 # copy source, as an indication that the test can run without hanging
 # with large size argument and to avoid opening pipe in blocking mode.
 #
+# Test both basic copy_range and copy_range -f availability
+_require_xfs_io_command "copy_range"
 _require_xfs_io_command "copy_range" "-f"
 
 testdir="$TEST_DIR/test-$seq"