CTDB API

[Andrew Tridgell]

Aleksey,

 > I guess, combining the calls in one function is not very good idea.
 > We'll have to implement big switch for multiplexing by the call id. And
 > what benefits shall we gain from single ctdb_call function?

We gain simplicity :-)

Also, I realised that a call like CTDB_REQ_FETCH, while being very
useful in a demo or in a test suite, isn't actually a good idea for
any of our real databases.

A CTDB_REQ_FETCH call implies that the caller wants to look at the
record. Why does it want to do that? To make a decision about the
record perhaps, such as if a open should be allowed? In that case it
would be much more efficient to make the decision on the DMASTER and
to just send the decision (an integer) to the caller, rather than
sending the whole record.

So if CTDB_REQ_FETCH doesn't actually make sense as a specialised call
for Samba, then what specialised calls do make sense? Not any that I
can think of :-)

So I'm now leaning towards just having the general CTDB_CALL, and each
database instance that uses ctdb will end up with quite different
calls that it actually implements.

I know this is a bit different to what I proposed in version 0.2 of
the CTDB proposal. That's what happens when you go to actually
implement something - you start to think about the problem a lot more
carefully :)

btw, in the little example I posted, I use TDB_DATA for all the data
blobs in struct ctdb_call. That wasn't supposed to imply that these
would be used only for tdb-style record contents and keys. Only the
'key', 'record_data' and 'new_data' fields contain things that always
directly relate to the tdb. The others may well contain data
structures, status codes etc.

A good example is the notion I called 'conditional append' in the
proposal. When I started looking at implementing this I realised that
the conditional append notion by itself wasn't sufficient, as we need
to trigger events on the caller that depend on data in the record on
the DMASTER. For example, there may be delayed opens, delayed locks,
oplocks etc that need to trigger when records update. The data needed
to make those calls is stored in the tdb record on the DMASTER, but it
only makes sense to actually trigger them on the caller. Solution? The
'reply_data' field will need to contain a structure which tells the
caller what was done on the DMASTER, so it can trigger the appropriate
events.

So this is getting more and more RPC like all the time. That isn't a
problem, it just means we need the more general CTDB_CALL approach and
the specific calls won't be sufficient.

btw, the 'big switch' isn't a problem at all, as the linked list of
registered calls for a specific database will be very short. I suspect
between 2 and 4 registered functions per database. That takes
nanoseconds to traverse (assuming hot in cache).

Cheers, Tridge