Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]

On 05/25/2012 02:48 AM, Paolo Bonzini wrote:

>>> * block-job-complete: force completion of mirroring and switching of the
>>> device to the target, not related to the rest of the proposal.
>>> Synchronously opens backing files if needed, asynchronously completes
>>> the job.
>>
>> Can this be made part of a 'transaction'?  Likewise, can
>> 'block-job-cancel' be made part of a 'transaction'?
> 
> Both of them are asynchronous so they would not create an atomic
> snapshot.  We could add it later, in the meanwhile you can wrap with
> fsfreeze/fsthaw.

It doesn't have to be right away, I just want to make sure that we
aren't excluding it from a possible future extension, because it _does_
sound useful.

> 
>> But now that you are adding the possibility of mirroring reverting
>> to copying, there is a race where I can probe and see that we are
>> in mirroring, then issue a 'block-job-cancel' to affect a copy operation,
>> but in the meantime things reverted, and the cancel ends up leaving me
>> with an incomplete copy.
> 
> Hmm, that's right.  But then this can only happen if you have an error
> in the target.  I can make block-job-cancel _not_ resume a paused job.
> Would that satisfy your needs?

I'm not sure I follow what you are asking.  My scenario is:

call 'drive-mirror' to start a job
'block-job-complete' fails because job is not ready, but the job is not
affected
wait for the event telling me we are in mirroring phase
start issuing my call to 'block-job-complete' to pivot
something happens where we are no longer mirroring
'block-job-complete' fails because we are not mirroring - good

call 'drive-mirror' to start a job
calling 'block-job-cancel' would abort the job, which is not what I want
wait for the event telling me we are in mirroring phase
start issuing my call to 'block-job-cancel' to cleanly leave the copy behind
something happens where we are no longer mirroring
'block-job-cancel' completes, but did not leave a complete mirror - bad

On the other hand, if I'm _not_ trying to make a clean copy, then I want
'block-job-cancel' to work as fast as possible, no matter what.

I'm not sure why having block-job-cancel resume or not resume a job
would make a difference.  What I really am asking for here is a way to
have some command (perhaps 'block-job-complete' but with an optional
flag set to a non-default value) that says I want to complete the job as
a clean copy, but revert back to the source rather than pivot to the
destination, and to cleanly fail with the job still around for
additional actions if I cannot get a clean copy at the current moment,
in the same way that the default 'block-job-complete' cleanly fails but
does not kill the job if I'm not mirroring yet.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]