On 2/5/21 10:37 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> The problem
>
> Assume we have mirror job with nbd target node with enabled reconnect.
> Connection failed. So, all current requests to nbd node are waiting for
> nbd driver to reconnect. And they will wait for reconnect-delay time
> specified in nbd blockdev options. This timeout may be long enough, for
> example, we in Virtuozzo use 300 seconds by default.
>
> So, if at this moment user tries to cancel the job, job will wait for
> its in-flight requests to finish up to 300 seconds. From the user point
> of view, cancelling the job takes a long time. Bad.
>
> Solution
>
> Let's just cancel "waiting for reconnect in in-flight request coroutines"
> on mirror (and backup) cancel. Welcome the series below.
>
> v2: wording, rebase on master, add Eric's r-bs, update test-output in
> last commit
Thanks; I'm queuing this through my NBD tree.
>
> Vladimir Sementsov-Ogievskiy (10):
> block: add new BlockDriver handler: bdrv_cancel_in_flight
> block/nbd: implement .bdrv_cancel_in_flight
> block/raw-format: implement .bdrv_cancel_in_flight handler
> job: add .cancel handler for the driver
> block/mirror: implement .cancel job handler
> iotests/264: move to python unittest
> iotests.py: qemu_nbd_popen: remove pid file after use
> iotests/264: add mirror-cancel test-case
> block/backup: implement .cancel job handler
> iotests/264: add backup-cancel test-case
>
> include/block/block.h | 3 +
> include/block/block_int.h | 9 +++
> include/qemu/job.h| 5 ++
> block/backup.c| 10 +++
> block/io.c| 11 +++
> block/mirror.c| 9 +++
> block/nbd.c | 15
> block/raw-format.c| 6 ++
> job.c | 3 +
> tests/qemu-iotests/264| 140 ++
> tests/qemu-iotests/264.out| 20 ++---
> tests/qemu-iotests/iotests.py | 6 +-
> 12 files changed, 172 insertions(+), 65 deletions(-)
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org