Re: [Qemu-devel] [RFC] Disk integrity in QEMU

[Jamie Lokier <jamie@shareable.org>]

Ian Jackson wrote:
> >  We've switched to always use O_DSYNC by default.  There was a very
> > long thread about it including benchmarks.  With the right posix-aio
> > tuning, we can use O_DSYNC without hurting performance*.
> 
> Right.
> 
> With the change in my tree, the guest can turn on the use of the
> host's buffer cache for writes (ie, turn off the use of O_DSYNC),
> using the appropriate cache control features in the IDE controller
> (and have write barriers with the FLUSH CACHE command).

I think this is a good idea in principle, but it needs to be
overridable by command line and monitor controls.

There are a number of guests and usages where you'd want to override
it.  These come to mind:

   - Enable host write caching even though the guest turns off IDE
     caching, because you're testing something and speed is more
     important than what the guest requests, and you don't want to or
     can't change the guest.

   - Disable host write caching even though the guest turns on IDE
     caching, because you know the guest enables the IDE cache for
     speed and does not flush the IDE cache for integrity (e.g. some
     old Linux or Windows?), and you don't want to or can't change the
     guest.

   - Disable host read and write caching with O_DIRECT, even though
     the guest turns on IDE caching, because you want to emulate
     (roughly) a real disk's performance characteristics.

   - Disable host read and write caching with O_DIRECT because you
     don't have spare RAM after the guests have used it.

Note that O_DIRECT is not strictly "less caching" than O_DSYNC.
Guest IDE FLUSH CACHE commands become host fsync/fdatasync calls.
On some Linux hosts, O_DSYNC + fsync will result in a _host_ IDE FLUSH
CACHE, when O_DIRECT + fsync will not.

-- Jamie