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

[Kevin Wolf <kwolf@redhat.com>]

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