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?
Regards,
Anthony Liguori