From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NXCEo-0002U2-C6
	for qemu-devel@nongnu.org; Tue, 19 Jan 2010 06:27:10 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NXCEj-0002Sd-An
	for qemu-devel@nongnu.org; Tue, 19 Jan 2010 06:27:09 -0500
Received: from [199.232.76.173] (port=57888 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NXCEj-0002SS-6M
	for qemu-devel@nongnu.org; Tue, 19 Jan 2010 06:27:05 -0500
Received: from mx1.redhat.com ([209.132.183.28]:24257)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1NXCEi-0004bM-Nr
	for qemu-devel@nongnu.org; Tue, 19 Jan 2010 06:27:05 -0500
Message-ID: <4B5596C7.1050701@redhat.com>
Date: Tue, 19 Jan 2010 12:25:59 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 01/10] qcow2: Fix error handling
	in	qcow2_grow_l1_table
References: <1263816696-24122-1-git-send-email-kwolf@redhat.com>	<1263816696-24122-2-git-send-email-kwolf@redhat.com>
	<20100119105843.GB12960@lst.de>
In-Reply-To: <20100119105843.GB12960@lst.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Am 19.01.2010 11:58, schrieb Christoph Hellwig:
> On Mon, Jan 18, 2010 at 01:11:27PM +0100, Kevin Wolf wrote:
>> Return the appropriate error value instead of always using EIO. Don't free the
>> L1 table on errors, we still need it.
>>
>> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> 
> Looks good correct, but shouldn't we free the clusters for the new l1
> table if writing to it fails?  At least dependend on whether it's EIO
> in which case we could assume the sectos on disk to be worn out.

Agreed, we should try to free them. At least in RHEV, the most likely
case for failure will be ENOSPC and we're going to succeed with the free
in that case.

This will become the first patch of the second series then. ;-)

Kevin