Anthony Liguori a écrit : > On 05/26/2010 03:52 AM, Aurelien Jarno wrote: >> On Tue, May 25, 2010 at 08:31:20PM -0500, Anthony Liguori wrote: >> >>> On 05/25/2010 04:01 PM, Aurelien Jarno wrote: >>> >>>> I really think this patch can be useful, in my own case when testing >>>> debian-installer (I already cache=writeback). In short all that is about >>>> developing and testing, as opposed to run a VM in production, can >>>> benefit about that. This was one of the original use case of QEMU before >>>> KVM arrived. >>>> >>>> Unless someone can convince me not to do it, I seriously considering >>>> applying this patch. >>>> >>> There really needs to be an indication in the --help output of what >>> the ramifications of this option are, in the very least. It should >>> >> That's indeed something than can be done, but to avoid double standards, >> it should also be done for other features that can lead to data >> corruption. I am talking for example on the qcow format, which is not >> really supported anymore. >> > > I agree. > >>> also be removable via a ./configure option because no sane >>> distribution should enable this for end users. >>> >>> >> I totally disagree. All the examples I have given apply to qemu *users*, >> not qemu developers. They surely don't want to recompile qemu for their >> usage. Note also that what is proposed in this patch was the default not >> too long ago, and that a lot of users complained about the new default >> for their usage, they see it as a regression. We even had to put a note >> explaining that in the Debian package to avoid to many bug reports. >> cache=writeback only answer partially to this use case. >> > > It's hard for me to consider this a performance regression because > ultimately, you're getting greater than bare metal performance (because > of extremely aggressive caching). It might be a regression from the > previous performance, but that was at the cost of safety.
For people who don't care about safety it's still a regression. And it is a common usage of QEMU. > We might get 100 bug reports about this "regression" but they concern > much less than 1 bug report of image corruption because of power > failure/host crash. A reputation of being unsafe is very difficult to > get rid of and is something that I hear concerns about frequently. > > I'm not suggesting that the compile option should be disabled by default > upstream. But the option should be there for distributions because I > hope that any enterprise distro disables it. > Which basically means those distro don't care about some use cases of QEMU, that were for most of them the original uses cases. It's sad. Sometimes I really whishes that KVM never tried to reintegrate code into QEMU, it doesn't bring only good things. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
