From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55482 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onsib-0003pL-6S for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:35:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnsiY-0001oa-Ms for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:35:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19138) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnsiY-0001oL-GQ for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:35:06 -0400 Message-ID: <4C73BC7A.9000409@redhat.com> Date: Tue, 24 Aug 2010 14:35:06 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes" References: <1282646430-5777-1-git-send-email-kwolf@redhat.com> <4C73AFBA.6000002@redhat.com> <4C73B364.1090900@suse.de> <4C73B6CE.4070205@redhat.com> <4C73B74B.5030105@suse.de> <4C73B87D.40303@redhat.com> <4C73B937.9050004@suse.de> <4C73BAA6.6000808@redhat.com> In-Reply-To: <4C73BAA6.6000808@redhat.com> 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: Avi Kivity Cc: Stefan Hajnoczi , hch@lst.de, mjt@tls.msk.ru, Alexander Graf , qemu-devel@nongnu.org Am 24.08.2010 14:27, schrieb Avi Kivity: > On 08/24/2010 03:21 PM, Alexander Graf wrote: >> Avi Kivity wrote: >>> On 08/24/2010 03:12 PM, Alexander Graf wrote: >>>>> Well, safety is not boolean. Considering to make it mostly safe instead >>>>> of completely safe because of the performance doesn't mean that we >>>>> should make it completely unsafe. >>>>> >>>> What is safety then? A vague feeling of "oh today is monday so my data >>>> is safe, but on tuesday I always lose my image data"? Either we promise >>>> to keep data safe or we don't. There is no in between. >>>> >>> Do you drive a car? >> Would you buy a car where the breaks are known to not always work? ;) > > That's not the case, even with cache=unsafe. > >>> Though in general I agree we shouldn't compromise on data integrity. >> That's my point. Either we go for it or we don't. > > I don't know how bad the performance regression is, and how large the > integrity risk is. I'd default towards preserving integrity, but maybe > this situation is different. I have reports of installations taking like 50 min instead of 14 min. My own qemu-io based test goes up from 1 s to 23 s. And I think the winner is Michael's image conversion which went up from 30 s to 49 min. So it's not like we're talking about just some 10 or 20 percent. Kevin