From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6kM6-00054q-Qf for qemu-devel@nongnu.org; Tue, 27 Apr 2010 08:57:38 -0400 Received: from [140.186.70.92] (port=42407 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6kM4-00054S-QV for qemu-devel@nongnu.org; Tue, 27 Apr 2010 08:57:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6kLu-0006kX-6X for qemu-devel@nongnu.org; Tue, 27 Apr 2010 08:57:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33292) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6kLt-0006k3-4X for qemu-devel@nongnu.org; Tue, 27 Apr 2010 08:57:26 -0400 Message-ID: <4BD6DF18.5010907@redhat.com> Date: Tue, 27 Apr 2010 14:56:56 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow2: Remove abort on free_clusters failure References: <1272364518-9386-1-git-send-email-kwolf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Am 27.04.2010 14:52, schrieb Stefan Hajnoczi: > On Tue, Apr 27, 2010 at 11:35 AM, Kevin Wolf wrote: >> --- a/block/qcow2-refcount.c >> +++ b/block/qcow2-refcount.c >> @@ -638,7 +638,7 @@ void qcow2_free_clusters(BlockDriverState *bs, >> ret = update_refcount(bs, offset, size, -1); >> if (ret < 0) { >> fprintf(stderr, "qcow2_free_clusters failed: %s\n", strerror(-ret)); >> - abort(); >> + /* TODO Remember the clusters to free them later and avoid leaking */ >> } >> } > > Has there been discussion on a fix mode for qemu-img check? For qcow2 > it could write new refcounts, calculated by traversing the L1/L2 > tables of the image and snapshots. Perhaps it would also dump out the > orphaned clusters to a lost+found. No real discussion, but it's somewhere among the low priority tasks on my todo list. So I agree this would make sense, at least for the trivial errors. Another thing I was considering is to distinguish between errors and warnings in qemu-img check. I keep getting reports about image corruption which turn out to be just some leaked clusters because they killed their qemu process at some point. Kevin