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