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. Vladimir Sementsov-Ogievskiy (11): 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: fix style 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 | 143 ++++++++++++++++++++++------------ tests/qemu-iotests/264.out | 20 ++--- tests/qemu-iotests/iotests.py | 6 +- 12 files changed, 173 insertions(+), 67 deletions(-) -- 2.21.3