> > Doing both fault injection and verification together introduces some > > subtlety. For example, even under the random failure mode, two disk writes > > triggered by one VM-issued write must either fail together or succeed > > together. Otherwise, the truth image and the test image will diverge and > > verification won't succeed. Currently, qemu-test carefully works with the > > 'sim' driver to guarantee those conditions. Those conditions need be > > retained after code restructure. > > If the real backend is a host system file or device, and AIO or > multi-threaded writes are used, you can't depend on two parallel disk > writes (triggered by one VM-issued write) failing together or > succeeding together. All you can do is look at the error code after > each operation completes, and use it to prevent issuing later > operations. You can't stop the other parallel operations that are > already in progress. > > Is that an issue in your design assumptions?
Your description of the problem is accurate, i.e., "if AIO or multi-threaded writes are used, you can't stop the other parallel operations that are already in progress." As a result, a naive extension of blkverify to test concurrent requests would not work. The simulated block driver (block/sim.c) in the FVD patch uses neither AIO or nor multi-threaded I/O as the backend. It instead uses a 'simulated' backend, which allows a full control of I/O order and callback order, and can enforce that two parallel disk writes (triggered by one VM-issued write) either failing together or succeeding together, and some other properties as well, which makes testing more comprehensive and debugging easier.
