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
