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.