From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhEvG-0002pn-Hb for qemu-devel@nongnu.org; Thu, 23 Oct 2014 05:43:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhEvA-0000TQ-CM for qemu-devel@nongnu.org; Thu, 23 Oct 2014 05:43:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhEvA-0000TI-5O for qemu-devel@nongnu.org; Thu, 23 Oct 2014 05:43:04 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9N9h21c019267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 05:43:02 -0400 Date: Thu, 23 Oct 2014 11:42:59 +0200 From: Kevin Wolf Message-ID: <20141023094259.GG3522@noname.redhat.com> References: <1413982283-10186-1-git-send-email-mreitz@redhat.com> <1413982283-10186-4-git-send-email-mreitz@redhat.com> <20141022183516.GA6975@noname.redhat.com> <5448B263.4050408@redhat.com> <20141023082957.GC3522@noname.redhat.com> <5448BDF6.9080406@redhat.com> <20141023084113.GD3522@noname.redhat.com> <5448C635.4080901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5448C635.4080901@redhat.com> Subject: Re: [Qemu-devel] [PATCH v13 03/14] qcow2: Optimize bdrv_make_empty() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 23.10.2014 um 11:11 hat Max Reitz geschrieben: > >>>Leaves the question, is it worth the hassle? > >>Probably not. Would you be fine with setting bs->drv to NULL in the > >>problematic error paths? > >By calling qcow2_signal_corruption(), right? I think that's fine. > > I don't know. The image isn't corrupted, it's just dirty. When you > open it, it'll work fine. I'd just output an own error here and set > bs->drv to NULL. Okay. > >What about the assumption that 3 + l1_size fits in one refcount block? > >Do we need to check it even now? > > The alternative would be not to allocate 3 + l1_size, but rather > just 3. Then we have a working refcount structure and that's the > most important thing (the L1 table is not yet accounted for, but > repair can fix that). > > Afterwards, we allocate the L1 table. With this change, we don't > know its offset yet, so we may have to change it again. But we can > easily do that by just setting s->l1_size to 0 and call > qcow2_grow_l1_table(). How do you make sure that the L1 table always stays zeroed then? And seriously, if you have an L1 table that doesn't fit in one refcount block, you're doing something wrong and deserve the slow fallback. Or, if we really want, we could zero out 2 + l1_size + num_rb clusters and hook up multiple refcount blocks. The new limit would then be at the point where the refcount table exceeds a cluster. Kevin