From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Sasha Levin <sashal@kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
Amir Goldstein <amir73il@gmail.com>,
Steve French <smfrench@gmail.com>,
<lsf-pc@lists.linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
"Luis R. Rodriguez" <mcgrof@kernel.org>
Subject: Re: [LSF/MM TOPIC] FS, MM, and stable trees
Date: Sat, 16 Feb 2019 13:28:35 -0500 [thread overview]
Message-ID: <20190216182835.GF23000@mit.edu> (raw)
In-Reply-To: <1550198902.2802.12.camel@HansenPartnership.com>
On Thu, Feb 14, 2019 at 06:48:22PM -0800, James Bottomley wrote:
> Well, we differ on the value of running regression tests, then. The
> whole point of a test infrastructure is that it's simple to run 'make
> check' in autoconf parlance. xfstests does provide a useful baseline
> set of regression tests. However, since my goal is primarily to detect
> problems in the storage path rather than the filesystem, the utility is
> exercising that path, although I fully appreciate that filesystem
> regression tests aren't going to catch every SCSI issue, they do
> provide some level of assurance against bugs.
>
> Hopefully we can switch over to blktests when it's ready, but in the
> meantime xfstests is way better than nothing.
blktests isn't yet comprehensive, but I think there's value in running
blktests as well as xfstests. I've been integrating blktests into
{kvm,gce}-xfstets because if the problem is caused to some regression
introduced in the block layer, I'm not wasting time trying to figure
out if it's caused by the block layer or not. It won't catch
everything, but at least it has some value...
The block/*, loop/* and scsi/* tests in blktests do seem to be in
pretty good shape. The nvme, nvmeof, and srp tests are *definitely*
not as mature.
- Ted
next prev parent reply other threads:[~2019-02-16 18:28 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 17:00 [LSF/MM TOPIC] FS, MM, and stable trees Sasha Levin
2019-02-12 21:32 ` Steve French
2019-02-13 7:20 ` Amir Goldstein
2019-02-13 7:37 ` Greg KH
2019-02-13 9:01 ` Amir Goldstein
2019-02-13 9:18 ` Greg KH
2019-02-13 19:25 ` Sasha Levin
2019-02-13 19:52 ` Greg KH
2019-02-13 20:14 ` James Bottomley
2019-02-15 1:50 ` Sasha Levin
2019-02-15 2:48 ` James Bottomley
2019-02-16 18:28 ` Theodore Y. Ts'o [this message]
2019-02-21 15:34 ` Luis Chamberlain
2019-02-21 18:52 ` Theodore Y. Ts'o
2019-03-20 3:46 ` Jon Masters
2019-03-20 5:06 ` Greg KH
2019-03-20 6:14 ` Jon Masters
2019-03-20 6:28 ` Greg KH
2019-03-20 6:32 ` Jon Masters
2022-03-08 9:32 ` Amir Goldstein
2022-03-08 10:08 ` Greg KH
2022-03-08 11:04 ` Amir Goldstein
2022-03-08 15:42 ` Luis Chamberlain
2022-03-08 19:06 ` Sasha Levin
2022-03-09 18:57 ` Luis Chamberlain
2022-03-11 5:23 ` Theodore Ts'o
2022-03-11 12:00 ` Jan Kara
2022-03-11 20:52 ` Luis Chamberlain
2022-03-11 22:04 ` Theodore Ts'o
2022-03-11 22:36 ` Luis Chamberlain
2022-04-27 18:58 ` Amir Goldstein
2022-05-01 16:25 ` Luis Chamberlain
2022-03-10 23:59 ` Steve French
2022-03-11 0:36 ` Chuck Lever III
2022-03-11 20:54 ` Luis Chamberlain
2022-03-08 16:40 ` Theodore Ts'o
2022-03-08 17:16 ` Amir Goldstein
2022-03-09 0:43 ` Dave Chinner
2022-03-09 18:41 ` Luis Chamberlain
2022-03-09 18:49 ` Josef Bacik
2022-03-09 19:00 ` Luis Chamberlain
2022-03-09 21:19 ` Josef Bacik
2022-03-10 1:28 ` Luis Chamberlain
2022-03-10 18:51 ` Josef Bacik
2022-03-10 22:41 ` Luis Chamberlain
2022-03-11 12:09 ` Jan Kara
2022-03-11 18:32 ` Luis Chamberlain
2022-03-12 2:07 ` Luis Chamberlain
2022-03-14 22:45 ` btrfs profiles to test was: (Re: [LSF/MM TOPIC] FS, MM, and stable trees) Luis Chamberlain
2022-03-15 14:23 ` Josef Bacik
2022-03-15 17:42 ` Luis Chamberlain
2022-03-29 20:24 ` [LSF/MM TOPIC] FS, MM, and stable trees Amir Goldstein
2022-04-10 15:11 ` Amir Goldstein
2022-03-08 10:54 ` Jan Kara
2022-03-09 0:02 ` Dave Chinner
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=20190216182835.GF23000@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@HansenPartnership.com \
--cc=amir73il@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mcgrof@kernel.org \
--cc=sashal@kernel.org \
--cc=smfrench@gmail.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 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).