From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S23uP-0007ZL-9t for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:58:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S23uJ-0006oV-8W for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:58:45 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:62187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S23uJ-0006oP-2b for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:58:39 -0500 Received: by pbbro12 with SMTP id ro12so6672852pbb.4 for ; Mon, 27 Feb 2012 08:58:37 -0800 (PST) Message-ID: <4F4BB639.6010200@codemonkey.ws> Date: Mon, 27 Feb 2012 10:58:33 -0600 From: Anthony Liguori 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> <4F4BB4A3.6080407@redhat.com> In-Reply-To: <4F4BB4A3.6080407@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paolo Bonzini Cc: Kevin Wolf , Jeff Cody , mtosatti@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Federico Simoncelli , Luiz Capitulino On 02/27/2012 10:51 AM, Paolo Bonzini wrote: > 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. Yes, maybe I lack imagination but I fail to see how it generalizes easily/nicely. From what I can tell, all of the rollback logic is very specific to the commands being used, right? Regards, Anthony Liguori > > Paolo