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). > > >> Frankly, I've started implementing this with virtlockd already, but the >> changes I made so far simply do not feel right, e.g. I have to change >> lock_protocol.x so that virLockSpaceProtocolAcquireResourceArgs has this >> 'type' argument which tells virtlockd which byte we want to lock. > > We could perhaps make use of the "flags" field, giving a flg to identify > the lockspace to use. This could be turned into an offset server side. Okay, I'll try this. Thanks! Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
