Am 05.03.2019 um 19:29 hat Eric Blake geschrieben:
> When iotest 223 was first written, it didn't matter if we waited for
> the qemu process to clean up. But with the introduction of a later
> qemu-nbd process trying to reuse the same file, there is a race where
> even though the asynchronous qemu process has responded to "quit", it
> has not yet had time to unlock the file and exit, resulting in:
>
> -[{ "start": 0, "length": 65536, "depth": 0, "zero": false, "data": false},
> -{ "start": 65536, "length": 2031616, "depth": 0, "zero": false, "data":
> true},
> -{ "start": 2097152, "length": 2097152, "depth": 0, "zero": false, "data":
> false}]
> +qemu-nbd: Failed to blk_new_open 'tests/qemu-iotests/scratch/t.qcow2':
> Failed to get shared "write" lock
> +Is another process using the image [tests/qemu-iotests/scratch/t.qcow2]?
> +qemu-img: Could not open
> 'driver=nbd,server.type=unix,server.path=tests/qemu-iotests/scratch/qemu-nbd.sock,x-dirty-bitmap=qemu:dirty-bitmap:b':
> Failed to connect socket tests/qemu-iotests/scratch/qemu-nbd.sock:
> Connection refused
> +./common.nbd: line 33: kill: (11122) - No such process
>
> Fixes: ddd09448
> Reported-by: Alberto Garcia <be...@igalia.com>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Makes sense to me. Berto, can you test it?
Kevin
