[libvirt] [PATCH] Introduce an internal API for handling file based lockspaces

[Daniel P. Berrange]

On Thu, Aug 02, 2012 at 05:20:52PM +0100, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange at redhat.com>
> 
> The previously introduced virFile{Lock,Unlock} APIs provide a
> way to acquire/release fcntl() locks on individual files. For
> unknown reason though, the POSIX spec says that fcntl() locks
> are released when *any* file handle refering to the same path
> is closed. In the following sequence
> 
>   threadA: fd1 = open("foo")
>   threadB: fd2 = open("foo")
>   threadA: virFileLock(fd1)
>   threadB: virFileLock(fd2)
>   threadB: close(fd2)
> 
> you'd expect threadA to come out holding a lock on 'foo', and
> indeed it does hold a lock for a very short time. Unfortunately
> when threadB does close(fd2) this releases the lock associated
> with fd1. For the current libvirt use case for virFileLock -
> pidfiles - this doesn't matter since the lock is acquired
> at startup while single threaded an never released until
> exit.
> 
> To provide a more generally useful API though, it is neccessary
> to introduce a slightly higher level abstraction, which is to
> be referred to as a "lockspace".  This is to be provided by
> a virLockSpacePtr object in src/util/virlockspace.{c,h}. The
> core idea is that the lockspace keeps track of what files are
> already open+locked. This means that when a 2nd thread comes
> along and tries to acquire a lock, it doesn't end up opening
> and closing a new FD. The lockspace just checks the current
> list of held locks and immediately returns VIR_ERR_RESOURCE_BUSY.
> 
> NB, the API as it stands is designed on the basis that the
> files being locked are not being otherwise opened and used
> by the application code. ie the files which are used to
> maintain the locks are not the files associated with the
> resources themselves. One approach to using this API is to
> acquire locks based on a hash of the filepath.
> 
> eg to lock /var/lib/libvirt/images/foo.img the application
> might do
> 
>    virLockSpacePtr lockspace = virLockSpaceNew("/var/lib/libvirt/imagelocks");
>    lockname = md5sum("/var/lib/libvirt/images/foo.img")
>    virLockSpaceAcquireLock(lockspace, lockname)
> 
> This patch is the basis for the soon to be re-submitted
> patch series providing a virtlockd daemon

Sorry, ignore this patch. I forgot to commit some other
local changes to it before sending. See the new v2.

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 :|