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
