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

[Kevin Wolf <kwolf@redhat.com>]

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

Am 11.04.2017 um 15:14 hat Eric Blake geschrieben:
> 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).

But that's not how things work. Essentially requesting completion means
that the next time that source and target are in sync, we complete the
block job. This means that still new copying requests can be issued
before the job actually completes (and it's even likely to happen).

> > 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.

This is not easily possible without implementing something like a backup
job for the final stage of the mirror job... Otherwise the guest can
always overwrite a sector that is still marked dirty and then that new
sector will definitely be copied still.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]