[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive
Date: Tue, 11 May 2010 10:40:08 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 05/11/2010 08:50 AM, Paul Brook wrote:
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.

The problem with options added for developers is that those options are
very often accidentally used for production.
I disagree.  We should not be removing or rejecting features just because they
allow you to shoot yourself in the foot.  We probably shouldn't be enabling
them by default, but that's a whole different question.

I disagree and think the mentality severely hurts usability. QEMU's role should be to enable features, not to simplify every obscure feature. In general, if someone wants to accomplish something, we should try to provide a mechanism to accomplish it. cache=none|writeback|writethrough is an example of this. No one other than QEMU can control how we open a file descriptor so we need to provide a knob for it.

But if the goal is to make sure that fsync's don't result in data actually being on disk, there are many other ways to accomplish this. First, for the vast majority of users, this is already the case because ext3 defaults to disabling barriers. Alex is running into this issue only because SuSE enables barriers by default for ext3 and fsync()'s are horribly slow on ext3. The fact that this is measurable is purely a statement of ext3 suckage and a conscious decision by the SuSE team to live with that suckage. It shouldn't be nearly as bad on ext4.

But even in this context, it's not a huge burden to disable barriers within the guest or to create a dedicated filesystem mount for your images on the host that disabled barriers on the mount.

On the other hand, the cost of adding another caching option is pretty significant. Very few users really understand what caching options they should use under what circumstance. Adding another option will just make that worse. The fact that this new option can result in data corruption that won't occur under normal circumstances is troubling.

Mounting a filesystem with barrier=0 is not a good answer because it's a
global setting.  While my qemu VM may be disposable, it's unlikely that the
same is true of the rest of my machine.

You can have multiple mounts. In fact, you can just make a loopback mount within your existing file system which means that you don't even have to muck with your disk.

If your VM is disposable, then shouldn't you be using -snapshot?

   By your argument linux shouldn't be
allowing me to do that in the first place because a dumb sysadmin could use
that option on the filesystem containing the mail store. In fact with the
average user that's *likely* to happen because they'll only have a single
partition on their machine.

We aren't preventing sophisticated users from doing sophisticated things. But why should we simplify something that most people don't need and if they accidentally use it, bad things will happen?


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]