From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXxNF-0003b2-Gm for qemu-devel@nongnu.org; Fri, 25 May 2012 12:28:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXxND-0004VE-Nw for qemu-devel@nongnu.org; Fri, 25 May 2012 12:28:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXxND-0004US-FC for qemu-devel@nongnu.org; Fri, 25 May 2012 12:28:19 -0400 Message-ID: <4FBFB31C.3040006@redhat.com> Date: Fri, 25 May 2012 18:28:12 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1336754931-20058-1-git-send-email-kwolf@redhat.com> <1336754931-20058-4-git-send-email-kwolf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] qcow2: Support for fixing refcount inconsistencies List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Am 25.05.2012 17:33, schrieb Stefan Hajnoczi: > On Fri, May 11, 2012 at 5:48 PM, Kevin Wolf wrote: >> @@ -1205,9 +1206,31 @@ int qcow2_check_refcounts(BlockDriverState *bs, BdrvCheckResult *res) >> >> refcount2 = refcount_table[i]; >> if (refcount1 != refcount2) { >> + >> + /* Check if we're allowed to fix the mismatch */ >> + int *num_fixed = NULL; >> + if (refcount1 > refcount2 && (fix & BDRV_FIX_LEAKS)) { >> + num_fixed = &res->leaks_fixed; >> + } else if (refcount1 < refcount2 && (fix & BDRV_FIX_ERRORS)) { >> + num_fixed = &res->corruptions_fixed; >> + } >> + >> fprintf(stderr, "%s cluster %d refcount=%d reference=%d\n", >> - refcount1 < refcount2 ? "ERROR" : "Leaked", >> + num_fixed != NULL ? "Repairing" : >> + refcount1 < refcount2 ? "ERROR" : >> + "Leaked", >> i, refcount1, refcount2); >> + >> + if (num_fixed) { >> + ret = update_refcount(bs, i << s->cluster_bits, 1, >> + refcount2 - refcount1); > > It would be nicer to use int64_t for i. I haven't checked but it > makes me nervous to shift ints here. Thanks, good catch. Fixed in block-next. Kevin