On Tue, Apr 19, 2016 at 02:36:05PM +0100, Richard W.M. Jones wrote: > > I'd prefer some kind of no lock / ignore lock. There is a legitimate > case where you want to have the shared lock behaviour, but also a > legitimate one for turning it off. I'm not opposed to the idea -- > there are very real cases where your patch saves people from > themselves.
[snip] > Off topic: How does this patch deal with genuinely shared (writable) > disks, as used in cluster filesystems? This series does add support for a lock_image=no parameter for disks which turns off all locking. IIUC, this was intended for use when the disk image must be shared between guests IOW, this series is doing the following: - read-only, exclusive -> F_RDLOCK - writable, shared -> no locking - writable, exclusive -> F_WRLOCK This stuff leaves open possibility of mistakes if one VM is given a disk in write+exclusive, while other VM gets the same disk in write+shared mode. In virtlockd we took a different approach to this: - read-only, exclusive -> no locking - writable, shared -> F_RDLOCK - writable, exclusive -> F_WRLOCK because this lets the kernel prevent case where the disk image is presented in write+shared mode to one VM and write+exlcusive mode to another VM. Not doing any locking at all in readonly case allowed for the scenario needed with libguestfs where they create an overlay for disks in use. 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 :|
