From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35085 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnsbA-0000bQ-5H for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:27:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onsb7-0000cz-VP for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:27:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18950) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onsb7-0000cg-PZ for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:27:25 -0400 Message-ID: <4C73BAA6.6000808@redhat.com> Date: Tue, 24 Aug 2010 15:27:18 +0300 From: Avi Kivity 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> In-Reply-To: <4C73B937.9050004@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Kevin Wolf , Stefan Hajnoczi , mjt@tls.msk.ru, qemu-devel@nongnu.org, hch@lst.de 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. -- error compiling committee.c: too many arguments to function