generic/564: fix copy_range -f availability test

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>
This commit is contained in:
Eric Sandeen
2019-09-12 11:15:49 -05:00
committed by Eryu Guan
parent d0f42706da
commit 298319fd4a
2 changed files with 3 additions and 1 deletions
+2
View File
@@ -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"