From: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To: Keith Busch <keith.busch@intel.com>, "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Omar Sandoval <osandov@osandov.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [LSF/MM TOPIC] improving storage testing
Date: Wed, 20 Feb 2019 01:33:24 +0000 [thread overview]
Message-ID: <SN6PR04MB4527328C158EFA37706D1BAF867D0@SN6PR04MB4527.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20190215173217.GA11055@localhost.localdomain
We deliberately check the generation counter to make sure discovery
code path is working as expected. The other text match is hardcoded
as per the cli, I sent out the tentative fixes so we can move forward.
I'll send another series to get rid of the all possible text based
comparisons so that we can avoid this scenario.
On 2/15/19 9:32 AM, Keith Busch wrote:
> On Thu, Feb 14, 2019 at 10:02:02PM -0500, Theodore Y. Ts'o wrote:
>>> My (undocumented) rule of thumb has been that blktests shouldn't assume
>>> anything newer than whatever ships on Debian oldstable. I can document
>>> that requirement.
>>
>> That's definitely not true for the nvme tests; the nvme-cli from
>> Debian stable is *not* sufficient. This is why I've started building
>> nvme-cli as part of the test appliance in xfstests-bld. I'm now
>> somewhat suspicious that there are problems because using the latest
>> HEAD of the nvme-cli git tree may have had messages printed to
>> standard out that is subtly different from the version of nvme-cli
>> that was used to develop some of the nvme tests.
>
> It does appear some expected output has hard coded values that are not
> fixed. Some of the failures are assuming an auto-incrementing generation
> number will always be 1, but that should just be a wildcard match.
>
prev parent reply other threads:[~2019-02-20 1:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 18:07 [LSF/MM TOPIC] improving storage testing Theodore Y. Ts'o
2019-02-14 7:37 ` Chaitanya Kulkarni
2019-02-14 10:55 ` Johannes Thumshirn
2019-02-14 16:21 ` David Sterba
2019-02-14 23:26 ` Bart Van Assche
2019-02-15 2:52 ` Chaitanya Kulkarni
2019-02-15 7:52 ` Johannes Thumshirn
2019-02-14 12:10 ` Lukas Czerner
2019-02-14 21:28 ` Omar Sandoval
2019-02-14 21:56 ` Omar Sandoval
2019-02-15 3:02 ` Theodore Y. Ts'o
2019-02-15 17:32 ` Keith Busch
2019-02-20 1:33 ` Chaitanya Kulkarni [this message]
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=SN6PR04MB4527328C158EFA37706D1BAF867D0@SN6PR04MB4527.namprd04.prod.outlook.com \
--to=chaitanya.kulkarni@wdc.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=osandov@osandov.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).