Re: [Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing "writeback" cache option

[Christoph Hellwig <hch@lst.de>]

On Thu, Jun 24, 2010 at 01:16:03AM +0100, Jamie Lokier wrote:
> Serge Hallyn wrote:
> > The default of qemu-img (of using O_SYNC) is not very sensible
> > because anyway, the client (the kernel) uses caches (write-back),
> > (and "qemu-nbd -d" doesn't flush those by the way). So if for
> > instance qemu-nbd is killed, regardless of whether qemu-nbd uses
> > O_SYNC, O_DIRECT or not, the data in the image will not be
> > consistent anyway, unless "syncs" are done by the client (like fsync
> > on the nbd device or sync mount option), and with qemu-nbd's O_SYNC
> > mode, those "sync"s will be extremely slow.
> 
> Do the "client syncs" cause the nbd server to fsync or fdatasync the file?

NBD does not have support for cache flushes.  Any nbd server needs to
use O_DSYNC-like semantics.

> I really wish qemu's options didn't give the false impression
> "nocache" does less caching than "writethrough".  O_DIRECT does
> caching in the disk controller/hardware, while O_SYNC hopefully does
> not, nowadays.

The current cache= options are misleading in many ways.  I'll post a
patchset soon to distangle the notion of using direct vs buffered I/O
from exposing and implementing a guest visible volatile write cache.

Exposing these improvements on the command linkes will have to wait for
the new -blockdev option.