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
