Re: [PATCH] fstests: test xfs_copy V5 XFS without -d option

[Dave Chinner <david@fromorbit.com>]

On Wed, Sep 21, 2016 at 07:00:20PM +0800, Zorro Lang wrote:
> From linux v4.3 and xfsprogs v4.2, xfs_copy support to copy a V5 XFS.
> Before that, copy a V5 XFS will cause target fs corruption, and only
> use "-d" option can resolve that problem.

What has the kernel version got to do with xfs_copy support?

What matters is whether xfsprogs supports a specific feature bit in
the XFS superblock - that is what indicates whether xfs_copy
requires the "-d" option or not....

> +# Make sure xfs_copy full support to copy V5 XFS, due to old xfs_copy can't
> +# yet copy V5 xfs without '-d'. But if xfs_copy can't copy V4 XFS, that's a
> +# bug.
> +_require_xfs_copy()
> +{
> +	_scratch_mkfs | _filter_mkfs 2>$tmp.mkfs >/dev/null
> +	. $tmp.mkfs
> +
> +	${XFS_COPY_PROG} $SCRATCH_DEV $tmp.copy >/dev/null 2>&1
> +	local rc=$?
> +
> +	rm -f $tmp.mkfs
> +	rm -f $tmp.copy 2>/dev/null
> +	if [ $rc -ne 0 ]; then
> +		if [ $_fs_has_crcs -eq 1 ]; then
> +			_notrun "This test requires xfs_copy support to copy V5 xfs without -d"
> +		else
> +			_fail "xfs_copy can't copy a V4 xfs"
> +		fi
> +	fi
> +}

Far too over engineered - the regression tests check whether the
functionality works correctly, not the _requires* check. The
_requires* check are just for determining whether the operation is
supported or not.

As I said above, xfs_copy on v5 filesystems do not require the
"-d" option if xfs_admin can change the UUID on v5 filesystems.
i.e. if this works:

# xfs_admin -U generate /dev/pmem1
Clearing log and setting UUID
writing all SBs
new UUID = b4e22c8b-1bfb-4307-a3f2-4f55b5c9d61d
# echo $?
0
#

Then xfs_copy does not require "-d" option. This works for both v4
and v5 filesystems, so this check can be done when setting up the
$XFS_COPY_PROG variable - there is no need for a _requires rule to
check this in every test.

-Dave.
-- 
Dave Chinner
david@fromorbit.com