> > 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. 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. 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. Paul N.B. in this context "developers" refers to users who happen to be using qemu as part of a toolset for development of $whatever, not development of qemu itself. c.f. "production" where qemu is part of the IT infrastructure used to directly provide an external service.