Re: [Qemu-devel] [PATCH v6 11/11] iotests: Add test for potentially damaging repairs

[Kevin Wolf]

Am 21.10.2014 um 16:20 hat Max Reitz geschrieben:
> On 2014-10-21 at 16:12, Kevin Wolf wrote:
> >Am 20.10.2014 um 16:35 hat Max Reitz geschrieben:
> >>There are certain cases where repairing a qcow2 image might actually
> >>damage it further (or rather, where repairing it has in fact damaged it
> >>further with the old qcow2 check implementation). This should not
> >>happen, so add a test for these cases.
> >>
> >>Furthermore, the repair function now repairs refblocks beyond the image
> >>end by resizing the image accordingly. Add several tests for this as
> >>well.
> >>
> >>Signed-off-by: Max Reitz <address@hidden>
> >>Reviewed-by: Eric Blake <address@hidden>
> >In case you didn't know: qemu-img handles hex offsets just fine, so
> >there's no need to comment the hex value and then convert it to decimal
> >for the real command.
> 
> Aha *g*
> 
> I did it that way in 060 and since then I just copied from there...
> 
> >>+--- Refblock is unallocated ---
> >>+
> >>+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
> >>+Repairing refcount block 1 is outside image
> >>+ERROR cluster 16 refcount=0 reference=1
> >>+Rebuilding refcount structure
> >>+Repairing cluster 1 refcount=1 reference=0
> >>+Repairing cluster 2 refcount=1 reference=0
> >>+Repairing cluster 16 refcount=1 reference=0
> >>+The following inconsistencies were found and repaired:
> >>+
> >>+    0 leaked clusters
> >>+    2 corruptions
> >>+
> >>+Double checking the fixed image now...
> >>+No errors were found on the image.
> >>+
> >>+--- Signed overflow after the refblock ---
> >>+
> >>+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
> >>+Repairing refcount block 1 is outside image
> >>+ERROR could not resize image: Invalid argument
> >>+Rebuilding refcount structure
> >>+Repairing cluster 1 refcount=1 reference=0
> >>+Repairing cluster 2 refcount=1 reference=0
> >>+The following inconsistencies were found and repaired:
> >>+
> >>+    0 leaked clusters
> >>+    1 corruptions
> >>+
> >>+Double checking the fixed image now...
> >>+No errors were found on the image.
> >This looks fishy. Compare this to the output of the previous case. We're
> >now missing the corruption for the refblock because *nb_clusters wasn't
> >increased.
> 
> I think we're rather missing the corruption for cluster 16
> refcount=0. And I'd find that completely fine.

Wasn't cluster 16 the additional refblock? Technically, it should now be
a corruption for cluster $HUGE_NUMBER, though I'll accept your excuse
below (for refblocks at least).

> >Don't we actually run the risk of allocating a clusters during the
> >refcount rebuild that was outside the image, but couldn't be repaired?
> >Perhaps a resize failure needs to stop the repair.
> 
> The other way would be to unconditionally call inc_refcounts().
> 
> But I think it does not matter either way. If the refcount structure
> is rebuilt, all current refblocks are leaked anyway, so overwriting
> them is not an issue, I think.

True. My concern was more about data blocks, but these are handled in a
different place. Nevertheless, I think inc_refcounts() could ignore them
with just a warning and a refcount rebuild would potentially overwrite
them.

Kevin