From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35945 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P0Agy-0007yV-Cp
	for qemu-devel@nongnu.org; Mon, 27 Sep 2010 06:12:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1P0Agx-0004eY-3u
	for qemu-devel@nongnu.org; Mon, 27 Sep 2010 06:12:16 -0400
Received: from mx1.redhat.com ([209.132.183.28]:38416)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1P0Agw-0004eR-Sh
	for qemu-devel@nongnu.org; Mon, 27 Sep 2010 06:12:15 -0400
Message-ID: <4CA06DF1.4030908@redhat.com>
Date: Mon, 27 Sep 2010 12:12:01 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 6/7] qed: Read/write support
References: <1285256514-21138-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<1285256514-21138-7-git-send-email-stefanha@linux.vnet.ibm.com>
In-Reply-To: <1285256514-21138-7-git-send-email-stefanha@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>

  On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote:
> This patch implements the read/write state machine.  Operations are
> fully asynchronous and multiple operations may be active at any time.
>
> Allocating writes are serialized to make metadata updates consistent.
> For example, two write requests to the same unallocated cluster should
> only allocate the new cluster once and then update it, rather than
> racing to allocate the cluster twice and losing on of the writes.  This
> scheme can be made more fine-grained in the future so that independent
> metadata updates can be active at the same time.
>

A comment re prefill-postfill - it seems to generate excessive I/O, for 
example an allocating write into the middle of a cluster will generate 
two reads (if a backing file exists) and three writes.  It would be 
simpler and more efficient to read the backing cluster, splice in the 
guest iovec, and issue a single write.  That is one read and two writes 
fewer.

(assuming I read the code right)

-- 
error compiling committee.c: too many arguments to function