From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1yZQ-00060e-8Q for qemu-devel@nongnu.org; Thu, 07 May 2009 04:03:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1yZL-0005vA-GD for qemu-devel@nongnu.org; Thu, 07 May 2009 04:03:07 -0400 Received: from [199.232.76.173] (port=47112 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1yZL-0005v0-Ay for qemu-devel@nongnu.org; Thu, 07 May 2009 04:03:03 -0400 Received: from mx20.gnu.org ([199.232.41.8]:55677) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M1yZK-0007ap-LD for qemu-devel@nongnu.org; Thu, 07 May 2009 04:03:02 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1yZK-0002QU-1G for qemu-devel@nongnu.org; Thu, 07 May 2009 04:03:02 -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 n47831Ju029945 for ; Thu, 7 May 2009 04:03:01 -0400 Message-ID: <4A029566.8040404@redhat.com> Date: Thu, 07 May 2009 10:01:42 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qcow2/virtio corruption: Don't allocate the same cluster twice References: <1241627950-22195-1-git-send-email-kwolf@redhat.com> <4A01C0C6.7020902@redhat.com> <4A01C2D4.5070000@redhat.com> <4A01C411.3060505@redhat.com> <4A01CE6C.3000901@redhat.com> <20090507073237.GY9795@redhat.com> In-Reply-To: <20090507073237.GY9795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: markmc@redhat.com, Avi Kivity , qemu-devel@nongnu.org Gleb Natapov schrieb: > The reason we need to copy unmodified sectors in alloc_cluster_link_l2() > is exactly to handle concurrent writes into the same cluster. This is > essentially RMW. I don't see why concurrent writes should not work with > the logic in place. There is a bug there currently of cause :) Can > somebody check this patch: > > > diff --git a/block-qcow2.c b/block-qcow2.c > index 7840634..801d26d 100644 > --- a/block-qcow2.c > +++ b/block-qcow2.c > @@ -995,8 +995,8 @@ static int alloc_cluster_link_l2(BlockDriverState *bs, uint64_t cluster_offset, > if(l2_table[l2_index + i] != 0) > old_cluster[j++] = l2_table[l2_index + i]; > > - l2_table[l2_index + i] = cpu_to_be64((cluster_offset + > - (i << s->cluster_bits)) | QCOW_OFLAG_COPIED); > + l2_table[l2_index + i] = cpu_to_be64(((cluster_offset + > + (i << s->cluster_bits)) | QCOW_OFLAG_COPIED)); > } > > if (bdrv_pwrite(s->hd, l2_offset + l2_index * sizeof(uint64_t), > @@ -1005,7 +1005,8 @@ static int alloc_cluster_link_l2(BlockDriverState *bs, uint64_t cluster_offset, > goto err; > > for (i = 0; i < j; i++) > - free_any_clusters(bs, be64_to_cpu(old_cluster[i]), 1); > + free_any_clusters(bs, be64_to_cpu(old_cluster[i]) & ~QCOW_OFLAG_COPIED, > + 1); > > ret = 0; > err: After Gleb explained to me how the whole thing is meant to work, I agree that this is the right fix. The first hunk is meaningless though. I suggest to replace it by a hunk adding a big comment explaining how things work. ;-) Kevin