From: Dave Chinner <david@fromorbit.com>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH v3 2/2] xfs/068: new fsstress operation breaks xfsrestore output
Date: Tue, 22 Jan 2019 09:44:12 +1100 [thread overview]
Message-ID: <20190121224412.GE4205@dastard> (raw)
In-Reply-To: <20190119024258.6864-2-zlang@redhat.com>
On Sat, Jan 19, 2019 at 10:42:58AM +0800, Zorro Lang wrote:
> After fsstress has new operation, xfs/068 has different dump output,
> so change the expected number of files and directories.
>
> Signed-off-by: Zorro Lang <zlang@redhat.com>
> ---
> tests/xfs/068.out | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/xfs/068.out b/tests/xfs/068.out
> index fa3a5523..f9ec37b8 100644
> --- a/tests/xfs/068.out
> +++ b/tests/xfs/068.out
> @@ -22,7 +22,7 @@ xfsrestore: session id: ID
> xfsrestore: media ID: ID
> xfsrestore: searching media for directory dump
> xfsrestore: reading directories
> -xfsrestore: 383 directories and 1335 entries processed
> +xfsrestore: 416 directories and 1373 entries processed
Shouldn't you tell fsstress to avoid this new operation so none of
the tests that rely on the number of files created by a specific
fstress seed break?
i.e. changing FSSTRESS_AVOID in common/dump as is done already to
turn off dedupe/clone/copy_file_range for xfsdump/restore tests?
Cheers,
dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-01-21 22:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-19 2:42 [PATCH v3 1/2] fsstress: add splice support Zorro Lang
2019-01-19 2:42 ` [PATCH v3 2/2] xfs/068: new fsstress operation breaks xfsrestore output Zorro Lang
2019-01-21 22:44 ` Dave Chinner [this message]
2019-01-22 3:33 ` Amir Goldstein
2019-01-22 4:58 ` Zorro Lang
2019-01-22 22:22 ` Dave Chinner
2019-01-23 3:44 ` Zorro Lang
2019-01-23 4:12 ` Dave Chinner
2019-01-23 7:35 ` Amir Goldstein
2019-01-23 8:41 ` Zorro Lang
2019-01-23 8:59 ` Amir Goldstein
2019-01-23 22:06 ` Dave Chinner
2019-01-24 9:28 ` Amir Goldstein
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=20190121224412.GE4205@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=zlang@redhat.com \
/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.