|
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
[Prev in Thread] | Current Thread | [Next in Thread] |