From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgbBG-0008Vw-12 for qemu-devel@nongnu.org; Tue, 21 Oct 2014 11:17:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgbB9-0007tS-RW for qemu-devel@nongnu.org; Tue, 21 Oct 2014 11:17:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgbB9-0007tF-Jy for qemu-devel@nongnu.org; Tue, 21 Oct 2014 11:16:55 -0400 Date: Tue, 21 Oct 2014 17:16:50 +0200 From: Kevin Wolf Message-ID: <20141021151650.GM4409@noname.redhat.com> References: <1413815733-22829-1-git-send-email-mreitz@redhat.com> <1413815733-22829-12-git-send-email-mreitz@redhat.com> <20141021141243.GJ4409@noname.redhat.com> <54466BB6.90604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54466BB6.90604@redhat.com> 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: Max Reitz Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , =?iso-8859-1?Q?Beno=EEt?= Canet 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 > >>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. 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