Re: [PATCH 1/2] check: add a -smoketest option

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Jul 25, 2023 at 05:05:24PM -0700, Darrick J. Wong wrote:
> 
> If someone wants that, then ok.  The taret audience for this are the
> drive-by filesystem patch authors.  IOWs, people who have some small bug
> they want to try to fix and want to run a quick test to see if their
> change works.

Zorro,

FYI, the context behind this was a comment I had made to Darrick that
the time necessary to run "-g quick" had been getting longer and
longer, and it might be nice to create a manually curated "-g smoke"
that was good enough for drive-by patch authors.  I was originally
thinking about a cut-down set of tests by selecting a subset of "-g
quick", but Darrick suggested that instead, we just run a very small
set of tests (mostly based on fsstress / fsx) and just run them in a
loop for 4 minutes or so.

We also talked about having a time budget (say, 15 minutes) and then
just dividing 15 time by the number of tests, and just run them in for
a specified soak time, so that the total time is known ahead of time.

To be honest, I was a bit dubious it could be that simple, but that's
where using kcov to show that you get a pretty good code coverage
using something that simple comes from.

> I don't think it's reasonable to expect drive-by'ers to know all that
> much about the fstests groups or spend the hours it takes to run -g all.
> As a maintainer, I prefer that these folks have done at least a small
> taste of QA before they start talking to the lists.

A big problem for the drive-by'ers is that that the top-level xfstests
README file is just plain scary, and has far too many steps for a
drive-by patch author to follow.

What I plan to add to a maintainer-entry-file.rst file for ext4 in the
kernel docs is to tell that drive-by posters that should run
"kvm-xfstests smoke" before submitting a patch, and setting up
kvm-xfstess is dead simple easy:


1)  Install kvm-xfstests --- you only have to run this once

% git clone https://github.com/tytso/xfstests-bld fstests
% cd fstests
% make ; make install

# Optional, if your file system you are developing isn't ext4;
# change f2fs to the file system of your choice
% echo PRIMARY_FSTYPE=f2fs >> ~/.config/kvm-xfstests


2) Build the kernel suitable for use with kvm-xfstests

% cd /path/to/your/kernel
% install-kconfig
% kbuild

3) Run the smoke test --- assuming the cwd is /path/to/your/kernel

(Note: today this runs -g quick, but it would be good if this could be
faster)

% kvm-xfstests smoke 


It's simple, and since the kvm-xfstests script will download a
pre-compiled test appliance image automatically, there's no need to
require the drive-by tester to figure out how compile xfstests with
any of its prerequisites.

And once things are set up, then it's just a matter of running
"kbuild" to build your kernel after you make changes, and running
"kvm-xfstests smoke" to do a quick smoke testing run.

No muss, no fuss, no dirty dishes...   :-)

Cheers,

					- Ted