From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhEwq-0003uE-O1 for qemu-devel@nongnu.org; Thu, 23 Oct 2014 05:44:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhEwk-0000ig-IX for qemu-devel@nongnu.org; Thu, 23 Oct 2014 05:44:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhEwk-0000ia-BL for qemu-devel@nongnu.org; Thu, 23 Oct 2014 05:44:42 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9N9if7T014118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 05:44:41 -0400 Message-ID: <5448CE06.2050706@redhat.com> Date: Thu, 23 Oct 2014 11:44:38 +0200 From: Max Reitz MIME-Version: 1.0 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> <20141023094259.GG3522@noname.redhat.com> In-Reply-To: <20141023094259.GG3522@noname.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi On 2014-10-23 at 11:42, Kevin Wolf wrote: > 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? Details... > 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. Probably so, yes. > 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. Well, if we're falling back to maths, v11 is always there. :-P Max