From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S22Rm-0004TM-EX for qemu-devel@nongnu.org; Mon, 27 Feb 2012 10:25:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S22Re-0007oY-Er for qemu-devel@nongnu.org; Mon, 27 Feb 2012 10:25:06 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:60624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S22Re-0007oI-8k for qemu-devel@nongnu.org; Mon, 27 Feb 2012 10:24:58 -0500 Received: by dadp14 with SMTP id p14so6393866dad.4 for ; Mon, 27 Feb 2012 07:24:57 -0800 (PST) Message-ID: <4F4BA044.5040208@codemonkey.ws> Date: Mon, 27 Feb 2012 09:24:52 -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> In-Reply-To: <4F4B9E73.3060601@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: Kevin Wolf Cc: Jeff Cody , mtosatti@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Federico Simoncelli , Paolo Bonzini , Luiz Capitulino On 02/27/2012 09:17 AM, Kevin Wolf wrote: > Am 27.02.2012 15:59, schrieb Anthony Liguori: >> On 02/27/2012 08:54 AM, Paolo Bonzini wrote: >>> On 02/27/2012 03:46 PM, Anthony Liguori wrote: >>>> I think a better way to think of this is as a batch submission. It >>>> would be relatively easy to model in QMP too (just have a batch-command >>>> that has a list of commands as it's argument). >>>> >>>> The difference between batch submission and a transaction is atomic >>>> rollback. But I don't think atomic rollback is really needed here. >>> >>> A transaction enforces atomicity at the block layer level. It's >>> different from batch commands in two ways: >>> >>> * bdrv_drain_all/bdrv_flush needs to be called at the beginning of the >>> commit. This may not be the case with batch commands. >>> >>> * with batch commands, atomicity happens by chance because VCPUs cannot >>> send I/O while the monitor is holding the global mutex. >> >> If the commands are designed correctly, then this works well. The problem is >> that the current commands are not designed well. For instance, multi-snapshot >> could look like: >> >> block-freeze ide0-hd0 >> block-freeze ide1-hd1 >> block-reopen ide0-hd0 my-new-file0.qcow2 >> block-reopen ide1-hd1 my-new-file1.qcow2 >> block-unfreeze ide1-hd1 >> block-unfreeze ide1-hd0 >> >> This would work regardless of whether the commands were implemented >> asynchronously within QEMU too. > > What if block-reopen ide1-hd1 fails? In case of failure, you want both > drives to point to their old image, not the first one to the new image > and the second one to the old image. 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. Regards, Anthony Liguori > > Kevin