Re: [Qemu-devel] [PATCH v13 03/14] qcow2: Optimize bdrv_make_empty()

[Max Reitz <mreitz@redhat.com>]

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