Re: [Qemu-devel] [PATCH v2] qapi: converted commit

[Pavel Hrdina <phrdina@redhat.com>]

On 06/14/2012 02:18 PM, Eric Blake wrote:
> On 06/14/2012 01:35 AM, Pavel Hrdina wrote:
>> Signed-off-by: Pavel Hrdina<phrdina@redhat.com>
>> ---
>> +++ b/qapi-schema.json
>> @@ -1169,6 +1169,21 @@
>>   { 'command': 'block_resize', 'data': { 'device': 'str', 'size': 'int' }}
>>
>>   ##
>> +# @commit
>> +#
>> +# Commit changes to the disk images (if -snapshot is used) or backing files.
>> +#
>> +# @device: the name of the device or the "all" to commit all devices
>> +#
>> +# Returns: nothing on success
>> +#          If @device is not a valid block device, DeviceNotFound
>> +#          If a long-running operation is using the device, DeviceInUse
>> +#
>> +# Since: 1.2
>> +##
>> +{ 'command': 'commit', 'data': { 'device': 'str' }}
> Should we use this as an opportunity to make the command more powerful?
>   For example, integrating this with the 'transaction' command or a block
> job queried by 'query-block-jobs' to track its progress would be useful.
>   Also, suppose I have A<- B<- C.  Does 'commit' only do one layer (C
> into B), or all layers (B and C into A)?  That argues that we need an
> optional parameter that says how deep to commit (committing C into B
> only to repeat and commit B into A is more time-consuming than directly
> committing both B and C into A to start with).  When a commit is
> complete, which file is backing the device - is it still C (which
> continues to diverge, but now from the point of the commit) or does qemu
> pivot things to have the device now backed by B (and C can be discarded,
> particularly true if changes are now going into B which invalidate C).

What i find out is that 'commit' will commit changes only from C to B 
and qemu continues with C from the new commit point. I couldn't find a 
way to commit changes and go back to backing file. This should be 
supported by parameter and also as you mention that commit all changes 
through all snapshots should be supported by another parameter.
The 'transaction' feature would be nice to have too.

Pavel