CTDB - the 'Mainz' plan for clustered Samba

[tridge at samba.org]

Simo,

 > 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
modes. 

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
on.

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