[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactiona
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable |
Date: |
Tue, 11 Apr 2017 14:05:04 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 03.04.2017 um 22:29 hat John Snow geschrieben:
> On 03/24/2017 08:34 AM, Kashyap Chamarthy wrote:
> > While debugging some other issue, I happened to stumble across an old
> > libvirt commit[*] that adds support for pivot (whether QEMU should
> > switch to a target copy or not) operation as a result of issuing QMP
> > 'block-job-cancel' to a 'drive-mirror' (in libvirt parlance, "block
> > copy").
> >
> > In the libvirt commit message[*] Eric Blake writes:
> >
> > "[...] There may be potential improvements to the snapshot code to
> > exploit block copy over multiple disks all at one point in time.
> > And, if 'block-job-cancel' were made part of 'transaction', you
> > could copy multiple disks at the same point in time without pausing
> > the domain. [...]"
> >
>
> Oh, you want a transactional cancel to basically capitalize on the
> second completion mode of the mirror job.
>
> I have never really cared for the way this job works, because I don't
> think "canceling" a ready job is semantically valid (it's not canceled!
> We completed successfully, just using a different completion mode) --
> but if I am in the minority here I would cede that a transactional
> cancel would be a worthwhile thing to have.
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.
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.
Kevin
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable,
Kevin Wolf <=
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Eric Blake, 2017/04/11
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Kevin Wolf, 2017/04/11
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Fam Zheng, 2017/04/12
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Kevin Wolf, 2017/04/12
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Fam Zheng, 2017/04/12