FS/XFS testing framework
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eryu Guan <eguan@redhat.com>, fstests@vger.kernel.org
Subject: Re: [PATCH 3/4] common: append -d option to XFS_COPY_PROG when testing v5 xfs
Date: Wed, 11 Mar 2015 10:48:18 -0400	[thread overview]
Message-ID: <550055B2.3040308@sandeen.net> (raw)
In-Reply-To: <1426072534-12246-4-git-send-email-eguan@redhat.com>

On 3/11/15 7:15 AM, Eryu Guan wrote:
> xfs_copy doesn't work on v5 xfs without -d option, this fails xfs/073
> when testing xfs with MKFS_OPTIONS="-m crc=1" set.

Neat, I did not know about the "=~" trick ;)

Test xfs/073 adds -d already, but two -d's are accepted...

... but the xfs/073 fails due to the fallback to nouuid, forced by
the duplicate ID which is found:

@@ -17,6 +17,7 @@
 All copies completed.
 checking new image
 mounting new image on loopback
+retrying mount with nouuid option

Also:

* This will only work until crcs are made default
* If $TEST_DEV was made with CRCs then "crc=1" might not be in MKFS_OPTIONS,
  but xfs_copy of $TEST_DEV would still fail

But we only ever use it on $SCRATCH_DEV in tests today, and if/when
crcs are made default we can figure out how to test for that later...

Still, need some solution that doesn't fail the existing test.

We could just _notrun this test with crcs ... talking with hch, I wonder
if we even have a use for xfs_copy anymore.   A changed-uuid xfs_copy
will be very hard to do w/ v5 filesystems.

-Eric

> Signed-off-by: Eryu Guan <eguan@redhat.com>
> ---
>  common/rc | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/common/rc b/common/rc
> index 1ed9df5..ad87a18 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -2926,6 +2926,11 @@ init_rc()
>  	# Figure out if we need to add -F ("foreign", deprecated) option to xfs_io
>  	xfs_io -c stat $TEST_DIR 2>&1 | grep -q "is not on an XFS filesystem" && \
>  	export XFS_IO_PROG="$XFS_IO_PROG -F"
> +
> +	# xfs_copy doesn't work on v5 xfs yet without -d option
> +	if [ "$FSTYP" == "xfs" ] && [[ $MKFS_OPTIONS =~ crc=1 ]]; then
> +		export XFS_COPY_PROG="$XFS_COPY_PROG -d"
> +	fi
>  }
>  
>  # get real device path name by following link
> 


  reply	other threads:[~2015-03-11 14:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-11 11:15 [PATCH 0/4] some random small fixes Eryu Guan
2015-03-11 11:15 ` [PATCH 1/4] new: fix template for new case to use a single tab not four spaces Eryu Guan
2015-03-11 13:59   ` Eric Sandeen
2015-03-11 11:15 ` [PATCH 2/4] generic/027: discard mkdir error message Eryu Guan
2015-03-11 14:08   ` Eric Sandeen
2015-03-11 11:15 ` [PATCH 3/4] common: append -d option to XFS_COPY_PROG when testing v5 xfs Eryu Guan
2015-03-11 14:48   ` Eric Sandeen [this message]
2015-03-11 14:52     ` Eric Sandeen
2015-03-12  5:57     ` Eryu Guan
2015-03-11 11:15 ` [PATCH 4/4] xfs/073: be quiet about mouting with nouuid option Eryu Guan
2015-03-11 14:51   ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550055B2.3040308@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox