From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S23nv-0003aJ-LV for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:52:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S23nm-0005p3-RI for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:52:03 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:36716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S23nm-0005lz-KH for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:51:54 -0500 Received: by mail-pz0-f45.google.com with SMTP id p14so6487634dad.4 for ; Mon, 27 Feb 2012 08:51:54 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F4BB4A3.6080407@redhat.com> Date: Mon, 27 Feb 2012 17:51:47 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20120224170143.78f55d3e@doriath.home> <8eaeb022-ea20-4823-886a-e629bce1c776@zmail16.collab.prod.int.phx2.redhat.com> <20120227091215.7849e558@doriath.home> <4F4B7BCD.6000808@redhat.com> <20120227100645.3f36d52d@doriath.home> <4F4B95A5.3000804@redhat.com> <4F4B9761.3010601@codemonkey.ws> <4F4B9931.30708@redhat.com> <4F4B9A46.3090706@codemonkey.ws> <4F4B9E73.3060601@redhat.com> <4F4BA044.5040208@codemonkey.ws> In-Reply-To: <4F4BA044.5040208@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Jeff Cody , mtosatti@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Federico Simoncelli , Luiz Capitulino On 02/27/2012 04:24 PM, Anthony Liguori wrote: > > Then you get an error with the block devices still frozen. You can > execute another command to reopen back to the old image to roll back the > transaction. > > Pushing the rollback logic to the client does make the client interface > a bit more complicated and adds latency to the error path but it's much > easier than building a complex transaction infrastructure. > > And there are examples of this in the wild too. LDAP uses a similar > mechanism. Actually, have you seen Jeff's atomic snapshot patch? It really implements all that is needed to do transactions, and gets 100% ok error-recovery unlike the existing blockdev_snapshot_sync. It really looks like we can do better than client-side error management, and there is not that much complexity at all. Jeff could rework his patches to work with transaction begin/commit commands, and Federico can then add drive-reopen and drive-migrate on top. Paolo