Locking with CTDB

[Volker Lendecke]

On Thu, Nov 13, 2008 at 10:57:42AM +0100, Henning Henkel wrote:
> at the moment I'm writing at my diploma thesis in the ctdb orbit. I got 
> the impression that ctdb depends on the locking of the underlying 
> filesystem and so I'm a little confused why there's the need for an 
> extra ctdb and why this can't be done with multiple samba servers.
> 
> Maybe you can provide me some extra information on  the  matter of 
> locking or on the general approach of developing ctdb.

ctdb right now depends on the underlying cluster-wide
locking at one single moment: When it figures out that the
cluster configuration has changed, i.e. if nodes have left
the cluster or nodes have been rebooted etc. Ctdb uses one
arbitrating lock to determine one and only one recovery
master. This is a simple way to make sure we have the exact
same view of cluster membership as the underlying file
system has. So if the underlying fs has a split brain, ctdb
freaks out, if the underlying fs can not give us the lock,
we also do not proceed. It would certainly be possible to
replace this recovery master negotiation by some other
mechanism, but as GPFS provides brlocks, we use that.

For general samba-style locking this would be far, far too
slow though. Thus the need for ctdb. Ctdb stores its
databases in normal tdb files that require fcntl locking,
but this time these files are not stored in the cluster file
system. They are stored on local ext3 or so where fcntl
locking is fast. It is the main task of ctdb to work around
the slowness of the cluster file systems for small requests
and locking, making use of the fast local file systems.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20081113/5d1592af/attachment.bin