|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive |
Date: | Tue, 11 May 2010 12:15:58 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 05/11/2010 11:32 AM, Jamie Lokier wrote:
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.
qemu-img create -f raw foo.img 10G mkfs.ext3 foo.img mount -oloop,rw,barrier=1 -t ext3 foo.img mnt Works perfectly fine.
2. barrier=0 does _not_ provide the cache=off behaviour. It only disables barriers; it does not prevent writing to the disk hardware.
The proposal has nothing to do with cache=off.
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?
None of our cache= options should result in data corruption on power loss. If they do, it's a bug.
Regards, Anthony Liguori
-- Jamie
[Prev in Thread] | Current Thread | [Next in Thread] |