From: "Theodore Ts'o" <tytso@mit.edu>
To: Zorro Lang <zlang@redhat.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] check: add a -smoketest option
Date: Wed, 26 Jul 2023 21:36:27 -0400 [thread overview]
Message-ID: <20230727013627.GF30264@mit.edu> (raw)
In-Reply-To: <20230726205930.GC30264@mit.edu>
As an aside, while I was testing my updates to the kvm-quickstart[1]
documentation, I timed how long it takes to run "-g quick" for a basic
ext4 file system config with 4k blocks using a desktop NVMe SSD for
the test and scratch devices.
[1] https://github.com/tytso/xfstests-bld/blob/test/Documentation/kvm-quickstart.md
It took 62 minutes, or a little over an hour. Yowza! I hadn't
realized that "kvm-xfstests smoke" was now taking that long. It used
to be that using a slower SSD (an Intel SATA-attached SSD dating from
2008) I could run "-g quick" in 15 minutes. Clearly, things were a
lot simpler back then. :-)
Anyway, I definitely need to replace what "kvm-xfstests smoke" does
with something else much more abbrevuated before I start requesting
drive-by patch submitters to run an fstests "smoke test". Because an
hour isn't it. Ideally, I'd like to keep it under 10 minutes if at
all possible, but we still want the testing to be likely to detect
most of the sort of simple problems that a drive-by patch submitter
might be likely find....
The fundamental question is how to do get the maximal amount of value
given a limited test budget.
- Ted
next prev parent reply other threads:[~2023-07-27 1:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 1:10 [PATCHSET 0/2] fstests: testing improvements Darrick J. Wong
2023-07-19 1:10 ` [PATCH 1/2] check: add a -smoketest option Darrick J. Wong
2023-07-19 15:10 ` Zorro Lang
2023-07-19 15:29 ` Darrick J. Wong
2023-07-19 16:11 ` Zorro Lang
2023-07-20 2:27 ` Darrick J. Wong
2023-07-20 14:34 ` Zorro Lang
2023-07-26 0:05 ` Darrick J. Wong
2023-07-26 6:01 ` Theodore Ts'o
2023-07-26 14:54 ` Zorro Lang
2023-07-26 20:59 ` Theodore Ts'o
2023-07-27 1:36 ` Theodore Ts'o [this message]
2023-07-27 1:54 ` Darrick J. Wong
2023-07-27 3:25 ` Zorro Lang
2023-07-27 14:33 ` Theodore Ts'o
2023-07-27 15:30 ` Zorro Lang
2023-07-28 15:53 ` Theodore Ts'o
2023-07-19 1:11 ` [PATCH 2/2] check: generate gcov code coverage reports at the end of each section Darrick J. Wong
2023-07-19 16:19 ` Zorro Lang
2023-07-20 2:29 ` Darrick J. Wong
2023-07-20 14:24 ` Zorro Lang
2023-07-26 0:05 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2023-07-26 1:56 [PATCHSET v2 0/2] fstests: testing improvements Darrick J. Wong
2023-07-26 1:56 ` [PATCH 1/2] check: add a -smoketest option Darrick J. Wong
2023-07-27 19:04 ` Theodore Ts'o
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=20230727013627.GF30264@mit.edu \
--to=tytso@mit.edu \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@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 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).