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:57:44 +0200 Message-ID: <4C90D0D8.6070308@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> <4C90CA5A.1040200@redhat.com> <4C90CFB3.1000708@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]:7181 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753053Ab0ION50 (ORCPT ); Wed, 15 Sep 2010 09:57:26 -0400 In-Reply-To: <4C90CFB3.1000708@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Am 15.09.2010 15:52, schrieb Anthony Liguori: > On 09/15/2010 08:30 AM, Kevin Wolf wrote: >> 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. > > FWIW, we queued a run reverting the sync() stuff entirely as we were > aware of that. Should have results this morning. Okay. I think that will be helpful, even outside the context of QED. I'd be interested how much of a difference it really makes in your tests. Kevin