qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [Libguestfs] [PATCH] tests: regressions: m


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [Libguestfs] [PATCH] tests: regressions: make test-big-heap use a temporary empty file
Date: Wed, 21 Mar 2018 15:58:05 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/21/2018 03:44 PM, Kevin Wolf wrote:

You're right that file locking on a character device like /dev/null is
not going to work as expected, but is it a case where fcntl() actually
fails, or is it worse where the fcntl() claiming the locks "succeeds"
but doesn't do what we want?  That is, what were the actual error
messages you ran into?

$ qemu-img --version
qemu-img version 2.10.1(qemu-2.10.1-2.fc27)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ qemu-img info /dev/null
qemu-img: Could not open '/dev/null': Failed to get "consistent read" lock
Is another process using the image?

Not sure where the difference is, but I can't reproduce this on
upstream, neither git master nor the v2.10.1 tag:

Is it a case where file locking actually works, and more than one process is trying to lock /dev/null at once? (qemu-img info is short-lived, but could there be another longer-lived process also using /dev/null)?

Does using -r help (if the only reason you're telling qemu-img to operate on /dev/null is to probe qemu-img features, can you probe those same features without needing to write, which in turn requests less locking)?

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



reply via email to

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