Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable

[Eric Blake <eblake@redhat.com>]

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

On 04/11/2017 07:05 AM, Kevin Wolf wrote:

> 
> Note that job completion/cancellation aren't synchronous QMP commands.
> The job works something like this, where '...' means that the VM can run
> and submit new writes etc.:
> 
> 1. Start job: mirror_start
> ...
> 2. Bulk has completed: BLOCK_JOB_READY event
> ...
> 3. Request completion/cancellation: block-job-completet/cancel
> ...
> 4. Actual completion/cancellation: BLOCK_JOB_COMPLETED
> 
> The last one is the actual job completion that we want to be atomic for
> a group of nodes. Just making step 3 atomic (which is what including
> block-job-complete/cancel in transaction would mean) doesn't really buy
> us anything because the data will still change between step 3 and 4.

But as long as the data changes between steps 3 and 4 are written to
only one of the two devices, rather than both, then the disk contents
atomicity is guaranteed at the point where we stopped the mirroring (ie.
during step 3).

> 
> Now step 4 is reached for each job individually, and unless you stop the
> VM (or at least the processing of I/O requests), I don't see how you
> could reach it at the same time for all jobs.

The fact that the jobs complete independently (based on different
amounts of data to flush) is not problematic, if we are still guaranteed
that issuing the request altered the graph so that future writes by the
guest only go to one side, and the delay in closing is only due to
flushing write requests that pre-dated the job end request.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


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