From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgaIs-0006e9-Fx for qemu-devel@nongnu.org; Tue, 21 Oct 2014 10:20:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgaIm-0006VP-AD for qemu-devel@nongnu.org; Tue, 21 Oct 2014 10:20:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgaIm-0006VK-2Z for qemu-devel@nongnu.org; Tue, 21 Oct 2014 10:20:44 -0400 Message-ID: <54466BB6.90604@redhat.com> Date: Tue, 21 Oct 2014 16:20:38 +0200 From: Max Reitz MIME-Version: 1.0 References: <1413815733-22829-1-git-send-email-mreitz@redhat.com> <1413815733-22829-12-git-send-email-mreitz@redhat.com> <20141021141243.GJ4409@noname.redhat.com> In-Reply-To: <20141021141243.GJ4409@noname.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 11/11] iotests: Add test for potentially damaging repairs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , =?windows-1252?Q?Beno=EEt_Canet?= 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 >> Reviewed-by: Eric Blake > 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