Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O

[Anthony Liguori <anthony@codemonkey.ws>]

Jamie Lokier wrote:
> 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.
>   

Except that in an enterprise environment, you typically have battery 
backed disk cache.  It really doesn't matter though b/c in QEMU today, 
submitting the request blocks until it's completed anyway (which is 
nearly instant anyway since I/O is buffered).

Regards,

Anthony Liguori

> -- Jamie
>
>
>
>