qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Propose the Fast Virtual Disk (FVD) image format


From: Chunqiang Tang
Subject: Re: [Qemu-devel] [RFC] Propose the Fast Virtual Disk (FVD) image format that outperforms QCOW2 by 249%
Date: Tue, 18 Jan 2011 15:35:09 -0500

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]