From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [Qemu-devel] Re: KVM call minutes for Sept 14 Date: Wed, 15 Sep 2010 15:30:02 +0200 Message-ID: <4C90CA5A.1040200@redhat.com> References: <20100914144758.GA19949@x200.localdomain> <4C8F90A9.8030407@codemonkey.ws> <4C908418.9070301@redhat.com> <4C90BB8E.1020201@codemonkey.ws> <4C90BE28.7060008@redhat.com> <4C90C855.5010306@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:3523 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753235Ab0ION3p (ORCPT ); Wed, 15 Sep 2010 09:29:45 -0400 In-Reply-To: <4C90C855.5010306@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Am 15.09.2010 15:21, schrieb Anthony Liguori: > On 09/15/2010 07:38 AM, Kevin Wolf wrote: >> No, we don't really care if the L2 entry is on disk. If the guest want >> to have its data safe it needs to issue an explicit flush anyway. The >> only thing we want to achieve with bdrv_write_sync is to maintain the >> right order between metadata updates to survive a crash without corruption. >> > > Ah, yes, this is brand new :-) > > I was looking at my QED branch which is a few weeks old. Well, the whole bdrv_pwrite_sync thing is new - with your benchmarking you probably caught qcow2 at its worst performance in years. Initially I just blindly converted everything to be on the safe side, and now we need to optimize to get the performance back. There are probably some more syncs that can be removed in less common paths. Kevin