qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2] qapi: block-core: Clarify events emitted by


From: John Snow
Subject: Re: [Qemu-block] [PATCH v2] qapi: block-core: Clarify events emitted by 'block-job-cancel'
Date: Wed, 15 Nov 2017 14:15:57 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0


On 11/15/2017 04:09 AM, Kashyap Chamarthy wrote:
> When you cancel an in-progress live block operation with QMP
> `block-job-cancel`, it emits the event: BLOCK_JOB_CANCELLED.  However,
> when `block-job-cancel` is issued after `drive-mirror` has indicated (by
> emitting the event BLOCK_JOB_READY) that the source and destination
> remain synchronized:
> 
>     [...] # Snip `drive-mirror` invocation & outputs
>     {
>       "execute":"block-job-cancel",
>       "arguments":{
>         "device":"virtio0"
>       }
>     }
> 
>     {"return": {}}
> 
> It (`block-job-cancel`) will counterintuitively emit the event
> 'BLOCK_JOB_COMPLETED':
> 
>     {
>       "timestamp":{
>         "seconds":1510678024,
>         "microseconds":526240
>       },
>       "event":"BLOCK_JOB_COMPLETED",
>       "data":{
>         "device":"virtio0",
>         "len":41126400,
>         "offset":41126400,
>         "speed":0,
>         "type":"mirror"
>       }
>     }
> 
> But this is expected behaviour, where the _COMPLETED event indicates
> that synchronization has successfully ended (and the destination has a
> point-in-time copy, which is at the time of cancel).
> 
> So add a small note to this effect.  (Thanks: Max Reitz for reminding
> me of this on IRC.)
> 

I suppose this difference probably isn't covered in what was the
bitmaps.md doc file (we don't bother covering mirror there, only
backup); is it covered sufficiently in live-block-operations.rst ?

--js



reply via email to

[Prev in Thread] Current Thread [Next in Thread]