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
signature.asc
Description: OpenPGP digital signature
