CTDB - the 'Mainz' plan for clustered Samba

tridge at samba.org tridge at samba.org
Sun Oct 1 00:14:48 GMT 2006


 > Sorry I meant:
 > who was sending CTDB_REQUEST_DMASTER and who received CTDB_REPLY_DMASTER

I think you've demonstrated that we should have a ORIGINAL_REQID
field, just to make it clearer! Also there should be more diagrams :)

In version 0.1 of this proposal I had quite a different plan for the
CTDB_REQ_DMASTER request. I envisaged that it would be an async
request to the LMASTER, and that the LMASTER view of who is the
DMASTER would lag the real DMASTER. I changed that as it was too hard
to solidly prove that the system would handle all the possible failure

I also realised that this request will be relatively rare, so a two
hop response is OK. If we set the threshold for transferring the
DMASTER role to a LACOUNT of say 8 or 10, then the additional latency
of 1 extra packet is small compared to everthing else that is going

The great thing about the CTDB_REQ_CONDITIONAL_APPEND approach is that
it is just one round trip for most requests, and a remote node never
holds a lock! So we get essentially zero lock contention. That is a
huge difference from the CTDB_REQ_FETCH_LOCKED approach, which in turn
was a huge advance on the old "put tdb on shared storage" approach.

I think this system is going to be really fast :)

Cheers, Tridge

More information about the samba-technical mailing list