On Thu, Jul 28, 2011 at 1:15 PM, Christoph Hellwig <h...@lst.de> wrote: > On Thu, Jul 28, 2011 at 09:47:05AM +0200, Kevin Wolf wrote: >> > Indeed. This has come up a few times, and actually is a mostly trivial >> > task. Maybe we should give up waiting for -blockdev and separate cache >> > mode settings and allow a nocache-writethrough or similar mode now? It's >> > going to be around 10 lines of code + documentation. >> >> I understand that there may be reasons for using O_DIRECT | O_DSYNC, but >> what is the explanation for O_DSYNC improving performance? > > There isn't any, at least for modern Linux. O_DSYNC at this point is > equivalent to a range fdatasync for each write call, and given that we're > doing O_DIRECT the ranges flush doesn't matter. If you do have a modern > host and an old guest it might end up beeing faster because the barrier > implementation in Linux used to suck so badly, but that's not inhrent > to the I/O model. If you guest however doesn't support cache flushes > at all O_DIRECT | O_DSYNC is the only sane model to use for local filesystems > and block devices.
I can rebase this cache=directsync patch and send it: http://repo.or.cz/w/qemu/stefanha.git/commitdiff/6756719a46ac9876ac6d0460a33ad98e96a3a923 The other weird caching-related option I was playing with is -drive ...,readahead=on|off. It lets you disable the host kernel readahead on buffered modes (cache=writeback|writethrough): http://repo.or.cz/w/qemu/stefanha.git/commitdiff/f2fc2b297a2b2dd0cccd1dc2f7c519f3b0374e0d Stefan