From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37282 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OENtd-0001Xs-1f for qemu-devel@nongnu.org; Tue, 18 May 2010 10:35:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OENtb-0001dv-2m for qemu-devel@nongnu.org; Tue, 18 May 2010 10:35:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8225) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OEHRr-0001sy-Qm for qemu-devel@nongnu.org; Tue, 18 May 2010 03:42:44 -0400 Message-ID: <4BF244CB.9000508@redhat.com> Date: Tue, 18 May 2010 09:42:03 +0200 From: Kevin Wolf 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> <498275A3-F2DA-4C59-B8DF-302121442DE0@suse.de> <20100517200743.GI20356@shareable.org> In-Reply-To: <20100517200743.GI20356@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Paul Brook , Alexander Graf , hch@lst.de Am 17.05.2010 22:07, schrieb Jamie Lokier: > Alexander Graf wrote: >> >> On 17.05.2010, at 18:26, Anthony Liguori wrote: >> >>> On 05/17/2010 11:23 AM, Paul Brook wrote: >>>>>> I don't see a difference between the results. Apparently the barrier >>>>>> option doesn't change a thing. >>>>>> >>>>> Ok. I don't like it, but I can see how it's compelling. I'd like to >>>>> see the documentation improved though. I also think a warning printed >>>>> on stdio about the safety of the option would be appropriate. >>>>> >>>> I disagree with this last bit. >>>> >>>> Errors should be issued if the user did something wrong. >>>> Warnings should be issued if qemu did (or will soon do) something other than >>>> what the user requested, or otherwise made questionable decisions on the >>>> user's behalf. >>>> >>>> In this case we're doing exactly what the user requested. The only plausible >>>> failure case is where a user is blindly trying options that they clearly don't >>>> understand or read the documentation for. I have zero sympathy for complaints >>>> like "Someone on the Internet told me to use --breakme, and broke thinks". >>>> >>> >>> I see it as the equivalent to the Taint bit in Linux. I want to make it clear to users up front that if you use this option, and you have data loss issues, don't complain. >>> >>> Just putting something in qemu-doc.texi is not enough IMHO. Few people actually read it. >> >> But that's why it's no default and also called "volatile". If you prefer, we can call it cache=destroys_your_image. > > With that semantic, a future iteration of cache=volatile could even > avoid writing to the backing file at all, if that's yet faster. I > wonder if that would be faster. Anyone fancy doing a hack with the > whole guest image as a big malloc inside qemu? I don't have enough RAM :-) But then you'd probably want a separate RAM block driver instead of messing with cache options. Kevin