All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Thumshirn <jthumshirn@suse.de>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] improving storage testing
Date: Thu, 14 Feb 2019 11:55:07 +0100	[thread overview]
Message-ID: <20190214105507.GA9739@linux-x5ow.site> (raw)
In-Reply-To: <20190213180754.GX23000@mit.edu>

On Wed, Feb 13, 2019 at 01:07:54PM -0500, Theodore Y. Ts'o wrote:
> 2) Documenting what are known failures should be for various tests on
> different file systems and kernel versions.  I think we all have our
> own way of excluding tests which are known to fail.  One extreme case
> is where the test case was added to xfstests (generic/484), but the
> patch to fix it got hung up because it was somewhat controversial, so
> it was failing on all file systems.

How about having a wiki page, either in the respective filesystems wiki or a
common wiki, that show's the list of test that are expected to fail for kernel
version X?

This is something I'm desperately looking for for brtfs for example.

[...]

> 3) Making blktests more stable/useful.  For someone who is not a block
> layer specialist, it can be hard to determine whether the problem is a
> kernel bug, a kernel misconfiguration, some userspace component (such
> as nvme-cli) being out of date, or just a test bug.  (For example, all
> srp/* tests are currently failing in blktests upstream; I had to pull
> some not-yet-merged commits from Bart's tree in order to fix bugs that
> caused all of srp to fail.)
> 
> Some of the things that we could do include documenting what kernel
> CONFIG options are needed to successfully run blktests, perhaps using
> a defconfig list.

Or checking for specific CONFIG_* settings in a test's requires() via
/proc/config.gz. This obviously won't work with kernels that don't have it.
 
> Also, there are expectations about minimum versions of bash that can
> be supported; but there aren't necessarily for other components such
> as nvme-cli, and I suspect that it is due to the use of a overly new
> version of nvme-cli from its git tree.  Is that supposed to work, or
> should I constrain myself to whatever version is being shipped in
> Fedora or some other reference distribution?  More generally, what is
> the overall expectations that should be expected?  xfstests has some
> extremely expansive set of sed scripts to normalize shell script
> output to make xfstests extremely portable; will patches along similar
> lines something that we should be doing for blktests?

I think this is the root cause of the problems you've sent out mails for this
week. A lot of blktests test need filtering. See [1] as an example.

[1] https://github.com/osandov/blktests/pull/34

Byte,
	Johannes
-- 
Johannes Thumshirn                            SUSE Labs Filesystems
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

  parent reply	other threads:[~2019-02-14 10:55 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 [this message]
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

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=20190214105507.GA9739@linux-x5ow.site \
    --to=jthumshirn@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --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 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.