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

[Jamie Lokier]

Anthony Liguori wrote:
> >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.
> 
> 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).

Buffered I/O is less reliable in a sense.

With buffered I/O, if the host crashes, you may lose data that a
filesystem or database on the guest reported as committed to
applications.  That can result, on those rare occasions, in guest
journalled filesystem corruption (something that should be
impossible), and in database corruption or durability failure.

With direct I/O and write cache emulation (as described), when a guest
journalling filesystem or database reports data is committed, it has
much the same committment/durability guarantee that the same
applications would have running on the host.  Namely, the data has
reached the disk, and the disk has reported it's committed.

This may matter if you want to run those sort of applications in a
guest, which clearly people often do, especially with KVM or Xen.

Anecdote: This is already a problem in some environments.  I have a
rented virtual machine; it's running UML.  The UML disk uses O_SYNC
writes (nowadays), because buffered host writes resulted in occasional
guest data loss, and journalled filesystem corruption.  Unfortunately,
this is a performance slowdown, but it's better than occasional
corruption.  I imagine similar things apply with Qemu machines
occasionally.

-- Jamie