When testing with fstests the kdevops architecture has proven to find more issues than with a regular bare metal setup.
If using bare metal we have to consider that the host has its own filesystem. And if using virtualization behind the scenes we then have the filesystem where the OS for the guest will placed and the sparse files which will be used by each guest for its virtual NVMe drives. Then the guest may use another filesystem for the /media/sparsefiles/ mount point. And finally there is the target filesystem which is going to be tested.
Our expectations to see more issues with fstests when using loopback devices and spare files kdevops when testing with fstests has proven to be true, some of the bugs reported with kdevops are not easily reproduced by filesystem developers otherwise, and so the extra development guests which can be set up with CONFIG_KDEVOPS_BASELINE_AND_DEV have proven to be valuable to allow developers to reproduce the issue easily. This setup tends to expose more filesystem bugs than a direct real hardware setup.