CTDB - the 'Mainz' plan for clustered Samba

[Andrew Tridgell]

Aleksey,

 > As I understand, you're planning to use the same interaction/transport
 > layer as common Samba messaging? Or not? This means that all CTDB calls
 > have to be synchronous. And the messaging subsystem has to be modified
 > significantly.

I'm not planning on using the existing messaging code. I want us to be
able to take advantage of hardware messaging libraries, and I also
don't want to tie the code to Samba initially.

I think it is better to develop ctdb on top of tdb, and to have its
own test suite, API etc. We will probably borrow some of the existing
Samba code (maybe the events library for example) but not to have it
tied into Samba as closely as the messaging layer is.

I think the initial prototype could be developed in lib/tdb/ctdb, and
we add an extensive test suite that includes testing of nodes coming
up/down, of messaging failure and of randomised testing of operations
simulating what the opendb and brlock databases have to do. We might
possibly backend those onto raw tdb as well, so we have a comparison
so we know the code is working.

 > And will CTDB calls replace TDB in locking.c/brlock.c implementation (as
 > we did in vl-messaging branch)?

We don't need to decide that just yet, but yes, that is the most
likely initial approach. The alternative would be for for the ctdb API
to become part of the tdb api, and for us to use the ctdb API even
when running on a single node. The API shouldn't need to be tied to
having a cluster at all - its is just a different abstraction of tdb,
and one that happens to be very suitable for both Samba and
clustering.

Cheers, Tridge