From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M1cHt-0000je-P2
	for qemu-devel@nongnu.org; Wed, 06 May 2009 04:15:33 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M1cHo-0000es-DM
	for qemu-devel@nongnu.org; Wed, 06 May 2009 04:15:32 -0400
Received: from [199.232.76.173] (port=38272 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M1cHo-0000ef-AK
	for qemu-devel@nongnu.org; Wed, 06 May 2009 04:15:28 -0400
Received: from mx2.redhat.com ([66.187.237.31]:50362)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1M1cHn-0004r1-Vi
	for qemu-devel@nongnu.org; Wed, 06 May 2009 04:15:28 -0400
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n468FQYu001872
	for <qemu-devel@nongnu.org>; Wed, 6 May 2009 04:15:26 -0400
Message-ID: <4A0146E3.2090909@redhat.com>
Date: Wed, 06 May 2009 10:14:27 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Strange virtio regression on mainline and stable-0.10
References: <4A000C74.5020907@redhat.com> <4A0066D9.6030008@redhat.com>
In-Reply-To: <4A0066D9.6030008@redhat.com>
Content-Type: text/plain; charset=UTF-8
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.gnu.org/pipermail/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: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

Avi Kivity schrieb:
> Avi Kivity wrote:
>> Running the Fedora 10 installer on a virtio disk on current master and 
>> on v0.10.3 will cause the installer to complain when mounting the 
>> freshly formatted filesystems.
> 
> The problem is that qcow2 does a read-modify-write on 
> non-cluster-aligned writes.  So the following sequence triggers the bug:
> [...]
> 
> This could be solved by maintaining a hash table of refcounted RMW 
> copies for the disk.  When reading for a RMW, look up the hash table, if 
> there's a copy there, use it instead of reading it yourself.
> 
> We should also avoid the RMW for non-compressed, non-encrypted clusters, 
> as virtually ALL writes will be misaligned.

I don't think there is a RMW except for the COW case which is
unavoidable and obviously happens only once for each cluster. Do you see
any other places where this happens?

Kevin