| Message ID | 5003d229-a168-a7bb-96b7-db4eb096806b@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | generic/564: fix copy_range -f availability test | expand |
On Thu, Sep 12, 2019 at 11:15:49AM -0500, Eric Sandeen wrote: > 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> > diff --git a/common/rc b/common/rc > index e0b087c1..66c7fd4d 100644 > --- 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` > diff --git a/tests/generic/564 b/tests/generic/564 > index ee1786cc..4958b3b5 100755 > --- a/tests/generic/564 > +++ b/tests/generic/564 > @@ -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" >
diff --git a/common/rc b/common/rc index e0b087c1..66c7fd4d 100644 --- 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` diff --git a/tests/generic/564 b/tests/generic/564 index ee1786cc..4958b3b5 100755 --- a/tests/generic/564 +++ b/tests/generic/564 @@ -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"
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> ---