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 :|
