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