From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34083)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1VyZBR-0000Wy-Hu
	for qemu-devel@nongnu.org; Wed, 01 Jan 2014 22:43:03 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1VyZBL-0004tM-GQ
	for qemu-devel@nongnu.org; Wed, 01 Jan 2014 22:42:57 -0500
Received: from mx1.redhat.com ([209.132.183.28]:37165)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1VyZBL-0004tH-8Q
	for qemu-devel@nongnu.org; Wed, 01 Jan 2014 22:42:51 -0500
Date: Thu, 2 Jan 2014 11:42:38 +0800
From: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20140102034238.GA7317@stefanha-thinkpad>
References: <1386244972-528-1-git-send-email-xiawenc@linux.vnet.ibm.com>
	<1386244972-528-5-git-send-email-xiawenc@linux.vnet.ibm.com>
	<20131220142034.GB9296@stefanha-thinkpad.redhat.com>
	<52B7A697.40302@linux.vnet.ibm.com>
	<52B7D468.4060307@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52B7D468.4060307@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH V7 4/6] qcow2: cancel the modification on
 fail in qcow2_snapshot_create()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Cc: kwolf@redhat.com, Stefan Hajnoczi <stefanha@gmail.com>, jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com

On Mon, Dec 23, 2013 at 02:12:56PM +0800, Wenchao Xia wrote:
>   I have reconsidered the roll back process, there is many case we
> should take care, so it is better to summarize a general rule to do such
> cancel operations. I suggest: do a series of roll back operations,
> when one fail, skip following roll back operation. For snapshot create,
> the create action is:
> allocate new L1 -> refcount+1 -> allocate sn_list -> update header
> The mirrored rollback action can be:
> deallocate L1 <- refcount-1 <- deallocate sn_list <- restore header
> 
> When fail happens in rollback action, simply stop following ones.
> If you agree, I'd like to reorganize the patch as above.

I agree.  When the steps depend on each other we should skip further
operations when an error is returned in the failure path.  If the steps
are independent we can still safely clean up the independent parts.

Stefan