From: Lars Marowsky-Bree <lmb@suse.de>
To: David Teigland <teigland@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-cluster@redhat.com,
ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
Date: Wed Jul 20 11:33:23 2005 [thread overview]
Message-ID: <20050720162636.GL5416@marowsky-bree.de> (raw)
In-Reply-To: <20050720033546.GB9747@redhat.com>
On 2005-07-20T11:35:46, David Teigland <teigland@redhat.com> wrote:
> > 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.
> We don't have a need for that information yet; I'm hoping we won't ever
> need it in the kernel, but we'll see.
Hm, I'm thinking a service might have a good reason to want to know the
possible list of nodes as opposed to the currently active membership;
though the DLM as the service in question right now does not appear to
need such.
But, see below.
> There are at least two ways to handle this:
>
> 1. Pass cluster events and data into the kernel (this sounds like what
> you're talking about above), notify the effected kernel components, each
> kernel component takes the cluster data and does whatever it needs to with
> it (internal adjustments, recovery, etc).
>
> 2. Each kernel component "foo-kernel" has an associated user space
> component "foo-user". Cluster events (from userland clustering
> infrastructure) are passed to foo-user -- not into the kernel. foo-user
> determines what the specific consequences are for foo-kernel. foo-user
> then manipulates foo-kernel accordingly, through user/kernel hooks (sysfs,
> configfs, etc). These control hooks would largely be specific to foo.
>
> We're following option 2 with the dlm and gfs and have been for quite a
> while, which means we don't need 1. I think ocfs2 is moving that way,
> too. Someone could still try 1, of course, but it would be of no use or
> interest to me. I'm not aware of any actual projects pushing forward with
> something like 1, so the persistent reference to it is somewhat baffling.
Right. I thought that the node manager changes for generalizing it where
pushing into sort-of direction 1. Thanks for clearing this up.
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"
WARNING: multiple messages have this Message-ID (diff)
From: Lars Marowsky-Bree <lmb@suse.de>
To: David Teigland <teigland@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-cluster@redhat.com,
ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
Date: Wed, 20 Jul 2005 18:26:36 +0200 [thread overview]
Message-ID: <20050720162636.GL5416@marowsky-bree.de> (raw)
In-Reply-To: <20050720033546.GB9747@redhat.com>
On 2005-07-20T11:35:46, David Teigland <teigland@redhat.com> wrote:
> > 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.
> We don't have a need for that information yet; I'm hoping we won't ever
> need it in the kernel, but we'll see.
Hm, I'm thinking a service might have a good reason to want to know the
possible list of nodes as opposed to the currently active membership;
though the DLM as the service in question right now does not appear to
need such.
But, see below.
> There are at least two ways to handle this:
>
> 1. Pass cluster events and data into the kernel (this sounds like what
> you're talking about above), notify the effected kernel components, each
> kernel component takes the cluster data and does whatever it needs to with
> it (internal adjustments, recovery, etc).
>
> 2. Each kernel component "foo-kernel" has an associated user space
> component "foo-user". Cluster events (from userland clustering
> infrastructure) are passed to foo-user -- not into the kernel. foo-user
> determines what the specific consequences are for foo-kernel. foo-user
> then manipulates foo-kernel accordingly, through user/kernel hooks (sysfs,
> configfs, etc). These control hooks would largely be specific to foo.
>
> We're following option 2 with the dlm and gfs and have been for quite a
> while, which means we don't need 1. I think ocfs2 is moving that way,
> too. Someone could still try 1, of course, but it would be of no use or
> interest to me. I'm not aware of any actual projects pushing forward with
> something like 1, so the persistent reference to it is somewhat baffling.
Right. I thought that the node manager changes for generalizing it where
pushing into sort-of direction 1. Thanks for clearing this up.
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"
next prev parent reply other threads:[~2005-07-20 11:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-18 1:10 [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm David Teigland
2005-07-18 6:15 ` David Teigland
2005-07-19 11:24 ` [Ocfs2-devel] " Lars Marowsky-Bree
2005-07-19 15:52 ` Lars Marowsky-Bree
2005-07-19 22:30 ` David Teigland
2005-07-20 3:35 ` David Teigland
2005-07-20 11:33 ` Lars Marowsky-Bree [this message]
2005-07-20 16:26 ` Lars Marowsky-Bree
2005-07-19 17:19 ` [Linux-cluster] " Daniel Phillips
2005-07-19 19:48 ` [Ocfs2-devel] " Mark Fasheh
2005-07-20 0:48 ` Mark Fasheh
2005-07-19 23:11 ` [Ocfs2-devel] " David Teigland
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=20050720162636.GL5416@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.