From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call minutes for Sept 14 Date: Wed, 15 Sep 2010 07:26:54 -0500 Message-ID: <4C90BB8E.1020201@codemonkey.ws> References: <20100914144758.GA19949@x200.localdomain> <4C8F90A9.8030407@codemonkey.ws> <4C908418.9070301@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Kevin Wolf Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:61356 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751792Ab0IOM06 (ORCPT ); Wed, 15 Sep 2010 08:26:58 -0400 Received: by yxp4 with SMTP id 4so40187yxp.19 for ; Wed, 15 Sep 2010 05:26:57 -0700 (PDT) In-Reply-To: <4C908418.9070301@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/15/2010 03:30 AM, Kevin Wolf wrote: > Am 14.09.2010 17:11, schrieb Anthony Liguori: > >> On 09/14/2010 09:47 AM, Chris Wright wrote: >> >>> 0.13 >>> - if all goes well...tomorrow >>> >>> >> To tag, it may be thursday for announcement. I need to run a regression >> run tonight. >> >> >>> qed/qcow2 >>> - increase concurrency, performance >>> >>> >> To achieve performance, a block driver must: 1) support concurrent >> request handling 2) not hold the qemu_mutex for prolonged periods of time. >> >> QED never does (2) and supports (1) in all circumstances except cluster >> allocation today. >> >> qcow2 can do (1) for the data read/write portions of an I/O request. >> All metadata read/write is serialized. It also does (2) for all >> metadata operations and for CoW operations. >> >> These are implementation details though. The real claim of QED is that >> by having fewer IO ops required to satisfy a request, it achieves better >> performance especially since it achieves zero syncs in the cluster >> allocation path. qcow2 has two syncs in the cluster allocation path >> today. One sync is due to the refcount table. Another sync is due to >> the fact that it doesn't require fsck support. >> > The refcount table sync is the sync that allows not doing an fsck. For a > simple cluster allocation (no L2 allocation, no COW), we only have one > sync (which is still one sync too much in this path, so we must move it). > Don't you have to write both a reference count entry and update the L2 entry? Both calls would be bdrv_pwrite_sync, no? Regards, Anthony Liguori > Kevin >