Anthony Liguori wrote: > On 05/11/2010 08:12 AM, Paul Brook wrote: > >>>cache=always (or a more scary name like cache=lie to defend against > >>>idiots) > >>> > >>> Reads and writes are cached. Guest flushes are ignored. Useful for > >>> dumb guests in non-critical environments. > >>> > >>I really don't believe that we should support a cache=lie. There are > >>many other obtain the same results. For instance, mount your guest > >>filesystem with barrier=0. > >> > >Ideally yes. However in practice I suspect this is still a useful option. > >Is > >it even possible to disable barriers in all cases (e.g. NTFS under > >windows)? > > > >In a production environment it's probably not so useful - you're generally > >dealing with long lived, custom configured guests. > > > >In a development environment the rules can be a bit different. For example > >if > >you're testing an OS installer then you really don't want to be passing > >magic > >mount options. If the host machine dies then you don't care about the > >state of > >the guest because you're going to start from scratch anyway. > > > > Then create a mount point on your host and mount the host file system > under that mount with barrier=0.
Two reasons that advice doesn't work: 1. It doesn't work in many environments. You can't mount a filesystem with barrier=0 in one place and barrier=1 on a different point, and there's ofen only one host partition. 2. barrier=0 does _not_ provide the cache=off behaviour. It only disables barriers; it does not prevent writing to the disk hardware. If you are doing a transient OS install, ideally you want an amount equal to your free RAM not written to disk until the end. barrier=0 does not achieve that. > The problem with options added for developers is that those options are > very often accidentally used for production. We already have risky cache= options. Also, do we call fdatasync (with barrier) on _every_ write for guests which disable the emulated disk cache? -- Jamie