On Mon, Aug 06, 2018 at 12:01:03PM +0200, Michal Prívozník wrote:
On 08/06/2018 10:30 AM, Daniel P. Berrangé wrote:
So do we really need virtlockd for this? I mean, the whole purpose of it is to hold locks so that libvirtd can restart independently, without losing the lock attached. However, since the metadata lock will be held only for a fraction of a second and will be not held through more than a single API aren't we just fine with libvirtd holding the lock? The way I imagine this to work is the following:
There were two reasons for virtlockd. The first was the persistent holding of locks, but the other reasons is that POSIX fcntl() locks are horrific. If one thread has an FD open with a lock held, if another thread opens and closes the same underlying file, the first thread's lock will get dropped.
We can't be confident that other threads won't open the file, so the only way to be safe was to put locking in to a separate process where we know exactly what all threads are doing.
Ah. That's terrible. But IIUC avoidable by using OFDs instead (which are not available on BSD I presume).
Yep, OFD is a (nice) Linux-ism but only exists in pretty recent Linux, and no non-Linux OS, so we can't rely on it. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|