Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30

[Lars Marowsky-Bree <lmb@suse.de>]

On 2004-07-11T15:44:25,
   Daniel Phillips <phillips@istop.com> said:

> Unless you can prove that your userspace approach never deadlocks, the other 
> questions don't even move the needle.  I am sure that one day somebody, maybe 
> you, will demonstrate a userspace approach that is provably correct.  

If you can _prove_ your kernel-space implementation to be correct, I'll
drop all and every single complaint ;)

> Until then, if you want your cluster to stay up and fail over
> properly, there's only one game in town.  

This however is not true; clusters have managed just fine running in
user-space (realtime priority, mlocked into (pre-allocated) memory
etc).

I agree that for a cluster filesystem it's much lower latency to have
the infrastructure in the kernel. Going back and forth to user-land just
ain't as fast and also not very neat.

However, the memory argument is pretty weak; the memory for
heartbeating and core functionality must be pre-allocated if you care
that much. And if you cannot allocate it, maybe you ain't healthy enough
to join the cluster in the first place.

Otherwise, I don't much care about whether it's in-kernel or not.

My main argument against being in the kernel space has always been
portability and ease of integration, which makes this quite annoying for
ISVs, and the support issues which arise. But if it's however a common
component part of the 'kernel proper', then this argument no longer
holds.

If the infrastructure takes that jump, I'd be happy. Infrastructure is
boring and has been solved/reinvented so often there's hardly anything
new and exciting about heartbeating, membership, there's more fun work
higher up the stack.

> > There is one more advantage to group messaging and distributed
> > locking implemented within the kernel, that I hadn't originally
> > considered; it sure is sexy.
> I don't think it's sexy, I think it's ugly, to tell the truth.  I am
> actively researching how to move the slow-path cluster infrastructure
> out of kernel, and I would be pleased to work together with anyone
> else who is interested in this nasty problem.

Messaging (which hopefully includes strong authentication if not
encryption, though I could see that being delegated to IPsec) and
locking is in the fast-path, though.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company    \ 	-- Samuel Beckett