[cgl_discussion] Re: [dcl_discussion] ANNOUNCE: OSDL Clusters (foundational components)

Steven Dake sdake at mvista.com
Wed Nov 26 15:23:05 PST 2003

> I somehow managed to miss that too. I really should subscribe to the
> OSDL cluster list, it appears.
> > > There are also reasonably strong reasons arguing against implementing
> > > these in kernel space. I'm sure you have heard the summary of them:
> > > Maintenance, mainline / vendor acceptance etc.
> > Through our initiatives we have heard opinion of people who are planning
> > to produce products using Linux clustering technology (i.e. people who
> > are potential customers to the company you are working for ...), and
> > their opinion differs from yours.
> They are also free to have that opinion ;-)
> Vendors have a reasonably strict "Mainline first" policy for 2.6. How's
> the chances of getting it into the kernel proper there? I'm not asking
> tongue-in-cheek, I'm truely curious, because so far our assessment has
> been that it seemed to work well enough outside the kernel and was also
> much simpler to maintain.

While I would agree with Lars that userland is the best place to put the
clustering infrastructure (and this is indeed the method MontaVista is
taking when implementing the SA Forum APIs), I'd like to see what the
team at OSDL comes up with, even if it is in the kernel.  As a
community, we can only learn from whatever results from that effort...

The one place the kernel can really help, and should not be dismissed
lightly, is reliable totally ordered messaging.  This is a clear
requirement of any clustering infrastructure (including cluster
membership) and is best implemented by interrupt-driven timer sources. 
Without totally ordered messaging, properly implementing distributed
application failover for 100% of failure cases is (*not impossible, but
close*).  Totally ordered reliable messaging that doesn't violate
causility can be implemented in user space, but then poll must be used
to simulate timers, which really doesn't work that well.


More information about the cgl_discussion mailing list