Alexander Bokovoy ab at samba.org
Wed Nov 1 07:02:35 GMT 2006


tridge at samba.org wrote:
> Alexander,
>> int ctdb_set_conditional(struct ctdb_context *ctdb,
>> ctdb_conditional_fn fn, uint32_t condition_id, void *private);
>> - this function has to be executed on all dispatchers, with the
>> same set of conditional functions and IDs as all conditions have to
>> be the same on all DMASTERs and all nodes are potential DMASTERs.
> Something just occurred to me about this API that I think is worth 
> mentioning. It puts a fairly tight constraint on the architecture we 
> use for clustered Samba.
> The architecture I was imagining was:
> 1 or more smbd processes (as per normal Samba) 1 dispatcher daemon
> process
> each of the smbd processes would talk to the dispatcher daemon via a 
> unix domain socket (probably a dgram socket). The dispatcher daemon 
> would be the main 'ctdb' daemon, and would talk to the cluster.
> This is all fine, except that ctdb_set_conditional() implies passing
> a function pointer from the smbd process to the dispatcher daemon.
> This is needed as the dispatcher daemon acts as the DMASTER/LMASTER
> in the cluster, and the function needs to execute on the DMASTER.
> This means that in practical terms the dispatcher daemon has to be
> the same executable as smbd, a forked child. We can't have a
> standalone ctdb_daemon executable and meaningfully pass a function
> pointer from smbd to that daemon.
Exactly. THis is layed out in last sentence of my previous mail:
We thought that probably it makes sense to split dispatcher code as CTDB
layer (tdb, protocol, events, main()) and application-specific part
(Samba-specific code in this case) so that actual dispatcher daemon
would be produced by combining otherwise common CTDB 'library' and
application-specific hooks (conditions, triggers, parsers).

The key thing here that if we could abstract conditionals/triggers so
that they deal only with data in databases and all actual CIFS-specific
reactions would be in client code (smbd), it would not impose much
dependency fixing.

/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

More information about the samba-technical mailing list