> > Here are the unique features you've described beyond what qemu-io, > > blkdebug, and blkverify do: > > > > 1. New functionality > > * Control over ordering of I/O request submission and completion. > > * Random I/O generator (probably as new qemu-io command). > > > > 2. Enhancements to existing code: > > * Random chance of failing I/O in blkdebug. > > > > Do you agree with this or are there other unique features which are > > beyond small enhancements to existing code? > > > > I think the best strategy is to consolidate these as incremental > > patches that can be reviewed and merged independently.
Hi Stefan, I agree with the strategy you described. Among the things you summarized, 'random chance of failing I/O in blkdebug' is probably trivial to add. 'random I/O generator' (i.e., the currently stand-alone program qemu-test) may be able to be folded in as a qemu-io command. Controlling I/O order and callback order is the most significant change, which has already integrated as several qemu-io commands in the FVD patch. The purpose of controlling I/O order and callback order is to test race conditions under concurrent requests. It is implemented as the “sim” driver in block/sim.c, by following an event-driven simulation approach and maintaining an outstanding event list. The “sim” driver can either remain standalone or be folded into blkdebug.c. The latter case would require significant changes to blkdebug.c. 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. Best regards, Chunqiang Tang
