From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40696 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onrs5-0006dp-BW for qemu-devel@nongnu.org; Tue, 24 Aug 2010 07:40:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onrrz-0002LZ-MD for qemu-devel@nongnu.org; Tue, 24 Aug 2010 07:40:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20250) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onrrz-0002LR-Cc for qemu-devel@nongnu.org; Tue, 24 Aug 2010 07:40:47 -0400 Message-ID: <4C73AFBA.6000002@redhat.com> Date: Tue, 24 Aug 2010 13:40:42 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1282646430-5777-1-git-send-email-kwolf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: avi@redhat.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, hch@lst.de 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. > QEMU 0.12.5 has qcow2 sync metadata writes in commit > 37060c28e522843fbf6f7e59af745dfcb05b132c. Was the performance > regression spotted on 0.12.5 or 0.13? Both. You mean we should consider a 0.12.6 if we decide to revert? I think so far 0.12.5 was planned to be last 0.12.x release. Kevin