From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33868 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnsND-0007t8-7v for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:13:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnsNB-0006u1-LJ for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:13:03 -0400 Received: from cantor.suse.de ([195.135.220.2]:46742 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnsNB-0006tt-94 for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:13:01 -0400 Message-ID: <4C73B74B.5030105@suse.de> Date: Tue, 24 Aug 2010 14:12:59 +0200 From: Alexander Graf 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> In-Reply-To: <4C73B6CE.4070205@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: Kevin Wolf Cc: Stefan Hajnoczi , hch@lst.de, mjt@tls.msk.ru, avi@redhat.com, qemu-devel@nongnu.org Kevin Wolf wrote: > Am 24.08.2010 13:56, schrieb Alexander Graf: > >> Kevin Wolf wrote: >> >>> Am 24.08.2010 13:02, schrieb Stefan Hajnoczi: >>> >>> >>>> On Tue, Aug 24, 2010 at 11:40 AM, Kevin Wolf wrote: >>>> >>>> >>>>> This reverts commit 8b3b720620a1137a1b794fc3ed64734236f94e06. >>>>> >>>>> This fix has caused severe slowdowns on recent kernels that actually do flush >>>>> when they are told so. Reverting this patch hurts correctness and means that we >>>>> could get corrupted images in case of a host crash. This means that qcow2 might >>>>> not be an option for some people without this fix. On the other hand, I get >>>>> reports that the slowdown is so massive that not reverting it would mean that >>>>> people can't use it either because it just takes ages to complete stuff. It >>>>> probably can be fixed, but not in time for 0.13.0. >>>>> >>>>> Usually, if there's a possible tradeoff between correctness and performance, I >>>>> tend to choose correctness, but I'm not so sure in this case. I'm not sure with >>>>> reverting either, which is why I post this as an RFC only. >>>>> >>>>> I hope to get some more comments on how to proceed here for 0.13. >>>>> >>>>> >>>> Sometimes an improvement has a side effect and it makes sense to hold >>>> back the improvement until the side effect can be resolved. The >>>> period of time in which users could rely on qcow2 data integrity is >>>> small to none, I feel reverting the commit makes sense. >>>> >>>> >>> Right, that's the vague feeling I have, too. >>> >>> >> If we don't think of qcow2 as integer format, why don't we just default >> to cache=unsafe there then? That way you could keep all the syncs in >> place making it stable with cache=!unsafe, but the default for users >> would be fast albeit unsafe, which it already is. >> > > 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. > That said, what we should do is changing the cache mode to unsafe in > certain places in qemu-img, e.g. in convert for the destination image. > If it fails, you'll throw it away anyway. > That would be useful either way. Alex