|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands) |
Date: | Mon, 27 Feb 2012 08:59:18 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 |
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-hd0This would work regardless of whether the commands were implemented asynchronously within QEMU too.
Regards, Anthony Liguori
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |