qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH for-2.7 00/15] block: Lock images when opening


From: Daniel P. Berrange
Subject: Re: [Qemu-block] [PATCH for-2.7 00/15] block: Lock images when opening
Date: Wed, 13 Apr 2016 10:19:29 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote:
> Too many troubles have been caused by two processes writing to the same image
> unexpectedly. This series introduces automatical image locking into QEMU to
> avoid such tragedy. With this, the user won't be able to open the image from
> two processes (e.g. using qemu-img when the image is attached to the guest).
> 
> Underneath is the fcntl syscall that locks the local file, similar to what is
> already used in libvirt virtlockd.  Also because of that, we cannot directly
> apply fcntl lock on the image file itself, instead we open and lock
> "/var/tmp/.qemu-$sha1.lock", where $sha1 is derived from the image's full path
> as in realpath(3). This mechanism should be equally useful for the single host
> case, and it doesn't conflict with virtlockd when managed by libvirt.
> 
> The alternative file locking API on Linux, flock(2), cannot protect host NFS
> mount points, so it's not used.

Maybe I'm missing something, but since you are locking /var/tmp/.qemu-$sha1.lock
the question of NFS support is irrelevant. All your locks are only ever going
to apply within the local host, since /var/tmp is always a local filesystem,
regardless of whether the actual image is on NFS. IOW, even using fcntl() you
have no cross-host protection for NFS based images here.

BTW, looking again at the virtlockd code I notice that I had the good
idea to be very selective with our use of fcntl() - rather than locking
the entire file, we only lock a single byte at offset 0.

So it would be possible for QEMU to directly using fcntl() on the image
file, if it provided a non-zero offset to lock at. eg QEMU could lock
byte 1 and that shouldn't interact with virtlockd's lock at byte 0.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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