From: Amir Goldstein <amir73il@gmail.com>
To: Eryu Guan <guaneryu@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>, Zorro Lang <zlang@redhat.com>,
Eric Sandeen <sandeen@redhat.com>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
fstests <fstests@vger.kernel.org>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] xfs/068: Add fsstress generated file count to golden output
Date: Sun, 27 Jan 2019 10:00:28 +0200 [thread overview]
Message-ID: <CAOQ4uxiup2OxAnHrLRTzNQgoDCXDv26xhz3+Pev4TMVDJ8Vy9g@mail.gmail.com> (raw)
In-Reply-To: <20190127050217.GL2713@desktop>
On Sun, Jan 27, 2019 at 7:02 AM Eryu Guan <guaneryu@gmail.com> wrote:
>
> [I'm sorry that I've been absent from the discussion entirely.. I was
> busy with other tasks recently.]
>
> On Thu, Jan 24, 2019 at 10:33:10AM +0200, Amir Goldstein wrote:
> > This test has the number of files/dirs created by fsstress hardcoded
> > in golden output.
>
> This leads me to wonder if we could remove the hardcoded dir/entries
> number from the golden output and verify the counts on the fly? i.e. we
> count the dir/entries numbers that fsstress created and compare them
> with the numbers xfsrestore reports. So we don't have to worry about new
> ops in fsstress and xfs configurations.
>
posted v2 with a slightly different approach:
count the dir/entries numbers that fsstress created and compare them
with the *actual* numbers xfsrestore created instead of the numbers that
xfsrestore reports.
Sure, this removes test coverage for the accuracy of the report, but
that was really never the intention of the test and the report is really
wrong! (off by one dir from actual restored).
If someone really cares about validating the accuracy of xfsrestore report
in that test, that by all means, let someone read into xfsrestore and figure
out what the one directory stands for and either fix xfsrestore or work that
quirk into the test. As can be inferred, that someone is not going to be me.
Thanks,
Amir.
next prev parent reply other threads:[~2019-01-27 8:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 8:33 [PATCH 1/2] common/dump: do not override test cleanup trap Amir Goldstein
2019-01-24 8:33 ` [PATCH 2/2] xfs/068: Add fsstress generated file count to golden output Amir Goldstein
2019-01-27 5:02 ` Eryu Guan
2019-01-27 8:00 ` Amir Goldstein [this message]
2019-01-27 5:15 ` [PATCH 1/2] common/dump: do not override test cleanup trap Eryu Guan
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=CAOQ4uxiup2OxAnHrLRTzNQgoDCXDv26xhz3+Pev4TMVDJ8Vy9g@mail.gmail.com \
--to=amir73il@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=guaneryu@gmail.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--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.