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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
