[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] iotest 223 is flaky

From: Eric Blake
Subject: Re: [Qemu-block] iotest 223 is flaky
Date: Tue, 5 Mar 2019 12:24:02 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/5/19 10:10 AM, Alberto Garcia wrote:
I can make it fail by running it a few times:

223 1s ... - output mismatch (see 223.out.bad)
--- tests/qemu-iotests/223.out       2019-02-08 17:25:15.584387100 +0200
+++ tests/qemu-iotests/223.out.bad     2019-03-05 18:05:16.855223976 +0200
@@ -92,9 +92,10 @@
=== Use qemu-nbd as server === -[{ "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": 
+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]?

I haven't been able to reproduce it yet, but see what might be the problem:

_send_qemu_cmd $QEMU_HANDLE '{"execute":"quit"}' "return"

echo "=== Use qemu-nbd as server ==="

nbd_server_start_unix_socket -r -f $IMGFMT -B b "$TEST_IMG"

There was nothing in the qemu process to let go of t.qcow2 prior to the quit request. And although the quit command may have had time to reply over the socket that the command was accepted, there may still be a delay before the process actually dies, where under sufficient load, the qemu-nbd process can start up during that window.

Patch coming up; since I couldn't reproduce the failure, I'd appreciate if you could confirm if it seems to help in your setup.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]