Paul Brook wrote:
> On Monday 03 December 2007, Samuel Thibault wrote:
> > Anthony Liguori, le Mon 03 Dec 2007 09:54:47 -0600, a écrit :
> > > Have you done any performance testing?  Buffered IO should absolutely
> > > beat direct IO simply because buffered IO allows writes to complete
> > > before they actually hit disk.
> >
> > Since qemu can use the aio interface, that shouldn't matter.
> 
> Only if the emulated hardware and guest OS support multiple concurrent 
> commands.  IDE supports async operation, but not concurrent commmands. In 
> practice this means you only get full performance if you're using the SCSI 
> emulation.

With the IDE emulation, when the emulated "disk write cache" flag is
on it may be reasonable to report a write as completed when the AIO is
dispatched, without waiting for the AIO to complete. 

An IDE flush cache command would wait for all outstanding write AIOs
to complete, and then issue a flush cache (fdatasync) to the real
device before reporting it has completed.

That's roughly equivalent to what an IDE disk with write caching does,
and it would provide exactly the guarantees for safe storage to the
real physical medium that a journalling filesystem or database in the
guest requires.

If a guest doesn't use journalling with IDE write cache safely
(e.g. 2.4 Linux and earler), it can simply turn off the IDE "disk
write cache" flag, which is what it has to do on a real physical disk
too.

Terminating the qemu process abruptly might cancel some AIOs, but even
that is ok, as it's equivalent to pulling the power on a real disk
with uncommitted cached writes.

-- Jamie


Reply via email to