On Wed, Jul 26, 2023 at 09:36:27PM -0400, Theodore Ts'o wrote: > 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. Just out of curiosity, if you apply this patch and change kvm-xfstests smoke to run ./check -smoketest, how long does that actually take on your infrastructure? --D > - Ted
