From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXXAk-00055d-Vw for qemu-devel@nongnu.org; Wed, 20 Jan 2010 04:48:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXXAf-00055M-7X for qemu-devel@nongnu.org; Wed, 20 Jan 2010 04:48:21 -0500 Received: from [199.232.76.173] (port=56837 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXXAf-00055J-3P for qemu-devel@nongnu.org; Wed, 20 Jan 2010 04:48:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60787) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NXXAe-0000yl-PP for qemu-devel@nongnu.org; Wed, 20 Jan 2010 04:48:17 -0500 Message-ID: <4B56D11E.3090606@redhat.com> Date: Wed, 20 Jan 2010 10:47:10 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 07/10] qcow2: Improve error handling in update_refcount References: <1263816696-24122-1-git-send-email-kwolf@redhat.com> <1263816696-24122-8-git-send-email-kwolf@redhat.com> <20100119185128.GA31526@lst.de> In-Reply-To: <20100119185128.GA31526@lst.de> 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: Christoph Hellwig Cc: qemu-devel@nongnu.org Am 19.01.2010 19:51, schrieb Christoph Hellwig: > On Mon, Jan 18, 2010 at 01:11:33PM +0100, Kevin Wolf wrote: >> If update_refcount fails, try to undo any changes made so far to avoid >> inconsistencies in the image file. >> >> Signed-off-by: Kevin Wolf >> --- >> block/qcow2-refcount.c | 32 +++++++++++++++++++++++++------- >> 1 files changed, 25 insertions(+), 7 deletions(-) >> > >> + /* >> + * Try do undo any updates if an error is returned (This may succeed in >> + * some cases like ENOSPC for allocating a new refcount block) >> + */ >> + if (ret < 0) { >> + int dummy; >> + dummy = update_refcount(bs, offset, cluster_offset - offset, -addend); > > So we recursively call into update_refcount here. What happens an error > causes all updates to fail? We're only reverting writes that have succeeded. If reverting fails, there are no successful writes and update_refcount will be called with a length of 0 (which never fails). In the worst case we're only reverting one cluster less with each recursive call - however, I don't think that's a realistic scenario. Kevin