ZFS Test Suite (on NixOS)

[Mindavi]

Hi, I'm working on implementing a NixOS test that runs (a part of) the ZTS. During getting this all to work, I've come to a couple of questions:

1. What test suite is advised to run? Note that this test suite may run quite often. I'm not 100% sure what's allowed, but I'm trying to go for ~5 mins with a maximum of 10 minutes (had a quick chat on the nixos IRC, we came to this number as some random number that seems reasonable for such an important part of the OS). I think I should either pick some separate tests, or use the tags to select some important parts. I need some guidance on what are the most important tests (for integration).
   • I saw there's a 'sanity' runfile, but it takes ~40 mins to run (and a couple of tests fail, but I think that's solveable). Is that the most reasonable place to start looking? Which ones will be most useful for a quick smoketest?
2. How to debug failing tests? -> My assumption is that I should look at the generated logfiles, but it's quite verbose. Maybe there are some things to consider while looking at those?

I'd like to give the full suite a run at least once locally, but I'm running into some issues where it seems to stop doing anything for more than a couple of hours (I let it run for at least 9 hours, but when I saw it stopped logging any zed events I eventually killed it) / I saw that the kernel was complaining about hanging processes. I think it has to do with the tests that use fio. Any idea there? I could supply some logs if needed, but running the full test suite is not really my priority here.

Thanks for the great filesystem and the hard work!

[ghost]

sanity.run will be a good starting point. You can prune some of the longer tests based on the results of a run through it as you see fit. The sanity tests are mostly there as a quick check before we bother going through the full test suite, so it's already not comprehensive of course.

To debug you really only get what the logs give you. Each test has separate log files saved in the test_results dir, so you can only look at the logs for failing tests. There is quite a bit of extra info dumped by testfail callbacks in the failing test logs, such as dmesg, that can often be ignored. You can of course modify the test scripts to add further output as needed for debugging. Generally you're looking for the point at which the script fails, which will be just before the testfail callbacks run.

[Mindavi]

Sounds good. Using the sanity checks seems reasonable, the goal is not to get full coverage but more to do a quick smoke-check.