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

Reply via email to