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

Jon Maloy jon.maloy at ericsson.com
Wed Nov 26 15:51:54 PST 2003


/jon

Steven Dake wrote:


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

The other place the kernel is indispensable is when decent communication
performance is required. After all, there is a reason why TCP, UDP and
most
other protocols are implemented in kernel space. A TIPC in user land
would
no doubt be twice as slow as TCP, instead of the opposite.

Anyway, I can not see that avoiding kernel space is a goal by itself, as
long as it is
not intrusive and is stable enough to not cause crashes.




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.



Thanks

-steve



_______________________________________________

cgl_discussion mailing list

cgl_discussion at lists.osdl.org <mailto:cgl_discussion at lists.osdl.org> 

http://lists.osdl.org/mailman/listinfo/cgl_discussion
<http://lists.osdl.org/mailman/listinfo/cgl_discussion> 

  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/cgl_discussion/attachments/20031126/7746d7c0/attachment-0001.htm


More information about the cgl_discussion mailing list