From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=56993 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P5gfF-0006Al-Uf
	for qemu-devel@nongnu.org; Tue, 12 Oct 2010 11:21:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1P5gS0-0001yh-Ks
	for qemu-devel@nongnu.org; Tue, 12 Oct 2010 11:07:37 -0400
Received: from mx1.redhat.com ([209.132.183.28]:7783)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1P5gS0-0001yb-Eh
	for qemu-devel@nongnu.org; Tue, 12 Oct 2010 11:07:36 -0400
Message-ID: <4CB479D2.7030901@redhat.com>
Date: Tue, 12 Oct 2010 17:08:02 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1286552914-27014-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<1286552914-27014-7-git-send-email-stefanha@linux.vnet.ibm.com>
In-Reply-To: <1286552914-27014-7-git-send-email-stefanha@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support
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: Anthony Liguori <aliguori@us.ibm.com>, Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>

Am 08.10.2010 17:48, schrieb Stefan Hajnoczi:
> This patch implements the read/write state machine.  Operations are
> fully asynchronous and multiple operations may be active at any time.
> 
> Allocating writes lock tables to ensure metadata updates do not
> interfere with each other.  If two allocating writes need to update the
> same L2 table they will run sequentially.  If two allocating writes need
> to update different L2 tables they will run in parallel.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

I hope to review this in more detail tomorrow, but there's one thing I
already noticed: When allocating a cluster, but not writing the whole
cluster (i.e. requests involving COW), I think we need to flush after
the COW and before the cluster allocation is written to the L2 table to
maintain the right order. Otherwise we might destroy data that isn't
even touched by the guest request in case of a crash.

Kevin