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: Thu, 25 Jan 2018 12:59:29 +0800 [thread overview]
Message-ID: <20180125045926.GA4720@localhost> (raw)
In-Reply-To: <d49dfbf5-b6e4-43d2-c24d-5c493aa5bfe5@redhat.com>
On Wed, Jan 24, 2018 at 01:16:39PM -0600, Eric Blake wrote:
> On 01/24/2018 12:17 AM, Liang Li wrote:
> > We found that when doing drive mirror to a low speed shared storage,
> > if there was heavy BLK IO write workload in VM after the 'ready' event,
> > drive mirror block job can't be canceled immediately, it would keep
> > running until the heavy BLK IO workload stopped in the VM. This patch
> > fixed this issue.
>
> I think you are breaking semantics here. Libvirt relies on
> 'block-job-cancel' after the 'ready' event to be a clean point-in-time
> snapshot, but that is only possible if there is no out-of-order pending
> I/O at the time the action takes place. Breaking in the middle of the
> loop, without using bdrv_drain(), risks leaving an inconsistent copy of
> data in the mirror not corresponding to any point-in-time on the source.
>
> 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?
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-25 4:59 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 [this message]
2018-01-25 14:48 ` Eric Blake
2018-01-26 6:46 ` Liang Li
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=20180125045926.GA4720@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).