Re: [Qemu-devel] [RFC] Propose the Fast Virtual Disk (FVD) image format that outperforms QCOW2 by 249%

[Chunqiang Tang]

> > 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.