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

[Max Reitz]

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