public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lars Marowsky-Bree <lmb@suse.de>
To: David Teigland <teigland@redhat.com>, linux-kernel@vger.kernel.org
Cc: linux-cluster@redhat.com, ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
Date: Tue, 19 Jul 2005 17:52:14 +0200	[thread overview]
Message-ID: <20050719155214.GG13246@marowsky-bree.de> (raw)
In-Reply-To: <20050718061553.GA9568@redhat.com>

On 2005-07-18T14:15:53, David Teigland <teigland@redhat.com> wrote:

> Some of the comments about the dlm concerned how it's configured (from
> user space.)  In particular, there was interest in seeing the dlm and
> ocfs2 use common methods for their configuration.
> 
> The first area I'm looking at is how we get addresses/ids of other nodes.
> Currently, the dlm uses an ioctl on a misc device and ocfs2 uses a
> separate kernel module called "ocfs2_nodemanager" that's based on
> configfs.
> 
> I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use
> it (removing ocfs-specific stuff).  It still needs some work, but I'd like
> to know if this appeals to the ocfs group and to others who were
> interested in seeing some similarity in dlm/ocfs configuration.

Hi Dave, I finally found time to read through this.

Yes, I most definetely like where this is going!

> +/* TODO:
> +   - generic addresses (IPV4/6)
> +   - multiple addresses per node

The nodeid, I thought, was relative to a given DLM namespace, no? This
concept seems to be missing here, or are you suggesting the nodeid to be
global across namespaces?

Also, eventually we obviously need to have state for the nodes - up/down
et cetera. I think the node manager also ought to track this.

How would kernel components use this and be notified about changes to
the configuration / membership state?


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

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"


  reply	other threads:[~2005-07-19 16:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-18  6:15 [RFC] nodemanager, ocfs2, dlm David Teigland
2005-07-19 15:52 ` Lars Marowsky-Bree [this message]
2005-07-20  3:35   ` [Ocfs2-devel] " David Teigland
2005-07-20 16:26     ` Lars Marowsky-Bree
2005-07-19 17:19 ` [Linux-cluster] " Daniel Phillips
2005-07-20  0:48 ` Mark Fasheh
2005-07-20  4:16   ` David Teigland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050719155214.GG13246@marowsky-bree.de \
    --to=lmb@suse.de \
    --cc=linux-cluster@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=teigland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox