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
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.