From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQa6E-0001vE-50 for qemu-devel@nongnu.org; Mon, 30 Sep 2013 05:49:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VQa68-0000LE-2W for qemu-devel@nongnu.org; Mon, 30 Sep 2013 05:49:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQa67-0000L7-Qn for qemu-devel@nongnu.org; Mon, 30 Sep 2013 05:48:59 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8U9mx6W027451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Sep 2013 05:48:59 -0400 Message-ID: <52494907.1030301@redhat.com> Date: Mon, 30 Sep 2013 11:48:55 +0200 From: Max Reitz MIME-Version: 1.0 References: <1380119840-12672-1-git-send-email-mreitz@redhat.com> <1380119840-12672-3-git-send-email-mreitz@redhat.com> <20130927145452.GA4510@dhcp-200-207.str.redhat.com> In-Reply-To: <20130927145452.GA4510@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] qcow2: Free allocated L2 cluster on error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi On 2013-09-27 16:54, Kevin Wolf wrote: > Am 25.09.2013 um 16:37 hat Max Reitz geschrieben: >> If an error occurs in l2_allocate, the allocated (but unused) L2 cluster >> should be freed. >> >> Signed-off-by: Max Reitz >> --- >> block/qcow2-cluster.c | 4 ++++ >> 1 file changed, 4 insertions(+) > This needs an update of the reference output for test case 026 (both for > -nocache and writethrough). Yes, right. > Most of the changes look expected and good, like cluster leaks > disappearing. With -nocache, however, there are a few cases that failed > previously and result in successful writes now. It would be interesting > to see the explanation for these before we merge the patch. I personally don't see this cases. Could you give an example? Max