[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Linux-cluster] Re: [Clusters_sig] new dlm control/configuration

On 2005-03-31T14:54:19, David Teigland <teigland redhat com> wrote:

(This is just a forward of the reply I sent to that e-mail on the
rh-cluster list; sorry for the dup, but there wasn't a Cc)

> The dlm is now configured/controlled from user space using sysfs.  It
> depends on nothing in the kernel that's not already there and it's
> completely agnostic about who or what is controlling it from user space.
> (Another unrelated change is that it now uses SCTP intead of TCP.)
> Someone or thing in user space now just tells the dlm who the nodes are
> who are using it.  This happens per-lockspace, of course, as different
> groups of nodes may be using different lockspaces.

Ohhh! Great! This makes a whole lot of sense. I like it when my problems
begin to resolve themselves ;-)

If now only GFS and OCFS2 could be convinced to either share the same
DLM or at least the same APIs, I think we'd be a whole bunch of steps
closer to sanity.

Given that OCFS2 approach seems to be reasonably similar already (though
they use configfs/usysfs instead of sysfs directly for this), I think we
are > < this close.

Probably the GFS DLM is more sophisticated than the OCFS2 one, however
they also went that step further and exported it as "dlmfs". Maybe
that's something you could steal from them?

> A new command line program, dlm_tool, can be used to set up the dlm
> manually in which case it depends on no other software (much like using
> dmsetup with device-mapper.)  Of course, some sort of user-level
> membership system would usually be used to control the dlm instead of
> dlm_tool, but that's completely variable now (like using either LVM2 or
> EVMS over device-mapper).

That fits very well.

> We're interested in some feedback -- does this make the dlm more useful
> for you and the general public?  If not, what might?  We'd like to see
> this dlm be used beyond GFS and CLVM.  A roadblock in the past was the
> disparate clustering and membership managers.  While consolidation
> continues slowly on that front, the dlm should be able to move ahead by
> remaining agnostic.

I think this is a great step forward into the right direction. Thanks a

I'm just as skeptical as you are about in-kernel membership computation,
and all that might entail. I think that OCFS2 and GFS are converging
here already hints at the fact that this is a good idea to move forward

    Lars Marowsky-Brée <lmb suse de>

High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]