From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1lum-0008I5-QM for qemu-devel@nongnu.org; Wed, 06 May 2009 14:32:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1lui-0008CS-8P for qemu-devel@nongnu.org; Wed, 06 May 2009 14:32:20 -0400 Received: from [199.232.76.173] (port=52087 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1lui-0008CL-4q for qemu-devel@nongnu.org; Wed, 06 May 2009 14:32:16 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43547) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1luh-000744-Gk for qemu-devel@nongnu.org; Wed, 06 May 2009 14:32:15 -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 n46IWDYc013833 for ; Wed, 6 May 2009 14:32:13 -0400 Message-ID: <4A01D789.3000007@redhat.com> Date: Wed, 06 May 2009 21:31:37 +0300 From: Avi Kivity 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> In-Reply-To: <4A01CE6C.3000901@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: markmc@redhat.com, qemu-devel@nongnu.org Kevin Wolf wrote: >> I suggest retaining the part where you use inflight l2metas to layout >> data contiguously, but change alloc_cluster_link_l2() not to rely on >> n_start and nb_available but instead recompute them on completion. >> m->nb_clusters should never be zeroed for this to work. >> > > Is there even a reason why we need to copy the unmodified sectors in > alloc_cluster_link_l2() and cannot do that in alloc_cluster_offset() > before we write the new data? Then the callback wouldn't need to mess > around with figuring out which part must be overwritten and which one > mustn't. > Then you have the inverse problem, you need to only copy sectors which aren't under an inflight write, and if such an inflight write fails, you do need to copy them. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.