From: Liang Li <liliang.opensource@gmail.com>
To: Eric Blake <eblake@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Huaitong Han <hanhuaitong@didichuxing.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] block/mirror: fix fail to cancel when VM has heavy BLK IO
Date: Fri, 26 Jan 2018 14:46:50 +0800 [thread overview]
Message-ID: <20180126064647.GA12068@localhost> (raw)
In-Reply-To: <b54574f8-ff1a-24bd-f86f-d908447c3459@redhat.com>
On Thu, Jan 25, 2018 at 08:48:22AM -0600, Eric Blake wrote:
> On 01/24/2018 10:59 PM, Liang Li wrote:
> >>
> >> There's ongoing work on adding async mirroring; this may be a better
> >> solution to the issue you are seeing.
> >>
> >> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg05419.html
> >>
> > Hi Eric,
> >
> > Thinks for your information, I didn't know libvirt depends on 'block-job-cancel'
> > for some of the block related operations.
> >
> > It's seems a new interface should provided by qemu for use case that just
> > for aborting block job and don't care abort the mirror data integrality, and
> > libvirt can make use of this new interface.
> >
> > Do you think this is the right direction?
>
> I don't know if it is better to wait for the new async mirroring code to
> land, or to just propose a new QMP command that can force-quit an
> ongoing mirror in the READY state, but you are correct that the only
> safe way to do it is by adding a new command (or a new optional flag to
> the existing block-job-cancel command).
>
Active sync does not conflict with the new QMP command, no need to wait.
The current QMP command is:
{ 'command': 'block-job-cancel', 'data': { 'device': 'str', '*force': 'bool' } }
'force' has other meaning which is not used by libvirt, for the change, there
are 3 options:
a. Now that 'force' is not used by libvirt and it current semantic is not very useful,
we can change it's semantic to force-quit without syncing.
b. change 'force' from bool to flag, and bit 0 is used for it's original meaning.
c. add another bool parameter.
which is the best one?
Thanks!
Liang
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
next prev parent reply other threads:[~2018-01-26 7:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 6:17 [Qemu-devel] [PATCH] block/mirror: fix fail to cancel when VM has heavy BLK IO Liang Li
2018-01-24 19:16 ` Eric Blake
2018-01-25 4:59 ` Liang Li
2018-01-25 14:48 ` Eric Blake
2018-01-26 6:46 ` Liang Li [this message]
2018-01-26 14:04 ` Eric Blake
2018-01-29 3:48 ` Liang Li
2018-01-26 17:23 ` [Qemu-devel] [Qemu-block] " John Snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180126064647.GA12068@localhost \
--to=liliang.opensource@gmail.com \
--cc=eblake@redhat.com \
--cc=hanhuaitong@didichuxing.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.