Hey, [I posted the following on the relevant github PR[1], though I'm resending here to include the mailing lists and anyone who maybe doesn't follow github] The generation counter issue with NVMe target tests still seems to be an issue even after a few months. I've found people complaining about it on the list (@tytso) but I'm still seeing these failures in test nvme/002,016 and 017 with no obvious resolution. The change in PR 34[1] seems like the only sensible solution I've found so far (I've tested it to ensure it works). The generation counter is a static variable in the NVMe Target code that gets incremented any time the discovery information changes. My best guess is that the kernel started incrementing this for more reasons since the tests were written and now the tests are broken. IMO, masking these changes out as suggested in this PR is the best solution. Then, if we want to test the generation counter, create another test that ensures the counter changes after performing specific actions. If we do that, we can also remove the "modprobe -r" calls (which are necessary to reset the counter) and be able to support running the tests with the modules built-in (which would be very nice for people trying to test the kernel in VMs). One way or another, we need a solution that's less fragile than the current method. Thanks, Logan [1] https://github.com/osandov/blktests/pull/34
