qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Cody <jcody@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
	Liang Li <liliang.opensource@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Max Reitz <mreitz@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Huaitong Han <huanhuaitong@didichuxing.com>,
	Liang Li <liliangleo@didichuxing.com>
Subject: Re: [Qemu-devel] [PATCH v2 resend] block/mirror: change the semantic of 'force' of block-job-cancel
Date: Mon, 12 Mar 2018 22:13:59 -0400	[thread overview]
Message-ID: <20180313021359.GH12302@localhost.localdomain> (raw)
In-Reply-To: <000d9a00-7d66-f8e4-0760-04a7e246ed75@redhat.com>

On Fri, Mar 02, 2018 at 11:20:55AM -0500, John Snow wrote:
> 
> 
> On 03/02/2018 10:39 AM, Eric Blake wrote:
> > On 02/26/2018 08:05 PM, Liang Li wrote:
> >> 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.
> >>
> >> Libvirt depends on the current block-job-cancel semantics, which is that
> >> when used without a flag after the 'ready' event, the command blocks
> >> until data is in sync.  However, these semantics are awkward in other
> >> situations, for example, people may use drive mirror for realtime
> >> backups while still wanting to use block live migration.  Libvirt cannot
> >> start a block live migration while another drive mirror is in progress,
> >> but the user would rather abandon the backup attempt as broken and
> >> proceed with the live migration than be stuck waiting for the current
> >> drive mirror backup to finish.
> >>
> >> The drive-mirror command already includes a 'force' flag, which libvirt
> >> does not use, although it documented the flag as only being useful to
> >> quit a job which is paused.  However, since quitting a paused job has
> >> the same effect as abandoning a backup in a non-paused job (namely, the
> >> destination file is not in sync, and the command completes immediately),
> >> we can just improve the documentation to make the force flag obviously
> >> useful.
> > 
> > How does this interact with John's ongoing work to redo block job
> > semantics:
> > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06167.html
> > 
> >>
> >> Cc: Paolo Bonzini <pbonzini@redhat.com>
> >> Cc: Jeff Cody <jcody@redhat.com>
> >> Cc: Kevin Wolf <kwolf@redhat.com>
> >> Cc: Max Reitz <mreitz@redhat.com>
> >> Cc: Eric Blake <eblake@redhat.com>
> >> Cc: John Snow <jsnow@redhat.com>
> >> Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
> >> Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
> >> Signed-off-by: Liang Li <liliangleo@didichuxing.com>
> >> ---
> > 
> > But in isolation, the patch looks reasonable to me.
> > 
> > Reviewed-by: Eric Blake <eblake@redhat.com>
> > 
> 
> In fairness, this patch hit the list before mine did, so...
> 
> I think it'll be OK to accommodate -- I think. It just changes the
> nature of how fast the cancellation happens in mirror, which shouldn't
> muck around with the general flow of job management in general. I think.
> 
> Famous last words.
>

I think Kevin's pulled your series in through his branch, and this patch
conflicts with it.  Do we want to try to rebase this patch on top of your
series?

  reply	other threads:[~2018-03-13  2:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27  2:05 [Qemu-devel] [PATCH v2 resend] block/mirror: change the semantic of 'force' of block-job-cancel Liang Li
2018-03-02 15:39 ` Eric Blake
2018-03-02 16:20   ` John Snow
2018-03-13  2:13     ` Jeff Cody [this message]
2018-03-13  6:41       ` 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=20180313021359.GH12302@localhost.localdomain \
    --to=jcody@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=huanhuaitong@didichuxing.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=liliang.opensource@gmail.com \
    --cc=liliangleo@didichuxing.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).