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 <mre...@redhat.com>
Reviewed-by: Eric Blake <ebl...@redhat.com>
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.
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.
Max