| Message ID | 20210205163720.887197-1-vsementsov@virtuozzo.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mirror: cancel nbd reconnect | expand |
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(-) >
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 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(-)