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 <pbonz...@redhat.com> >> Cc: Jeff Cody <jc...@redhat.com> >> Cc: Kevin Wolf <kw...@redhat.com> >> Cc: Max Reitz <mre...@redhat.com> >> Cc: Eric Blake <ebl...@redhat.com> >> Cc: John Snow <js...@redhat.com> >> Reported-by: Huaitong Han <huanhuait...@didichuxing.com> >> Signed-off-by: Huaitong Han <huanhuait...@didichuxing.com> >> Signed-off-by: Liang Li <liliang...@didichuxing.com> >> --- > > But in isolation, the patch looks reasonable to me. > > Reviewed-by: Eric Blake <ebl...@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. --js