From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45301 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHHMl-0003Jp-Fs for qemu-devel@nongnu.org; Wed, 26 May 2010 10:13:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHHLv-0004jG-30 for qemu-devel@nongnu.org; Wed, 26 May 2010 10:13:00 -0400 Received: from hall.aurel32.net ([88.191.82.174]:53881) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHHLu-0004j8-Tl for qemu-devel@nongnu.org; Wed, 26 May 2010 10:12:59 -0400 Message-ID: <4BFD2C57.4050606@aurel32.net> Date: Wed, 26 May 2010 16:12:39 +0200 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive References: <1274091292-4812-1-git-send-email-agraf@suse.de> <4BF14CE9.5040907@suse.de> <4BF15DC8.8080104@codemonkey.ws> <201005171723.15675.paul@codesourcery.com> <4BF16E22.6090400@codemonkey.ws> <4BFC0FF6.1080005@suse.de> <20100525210113.GE1402@hall.aurel32.net> <4BFC79E8.1070700@codemonkey.ws> <20100526085248.GC21913@volta.aurel32.net> <4BFD269E.9090503@codemonkey.ws> In-Reply-To: <4BFD269E.9090503@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, Alexander Graf , hch@lst.de, Paul Brook , qemu-devel@nongnu.org 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 aurelien@aurel32.net http://www.aurel32.net