From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] cluster4 gfs_controld
Date: Thu, 13 Oct 2011 12:49:31 -0400 [thread overview]
Message-ID: <20111013164931.GD6704@redhat.com> (raw)
In-Reply-To: <1318522589.2719.38.camel@menhir>
On Thu, Oct 13, 2011 at 05:16:29PM +0100, Steven Whitehouse wrote:
> Hi,
>
> On Thu, 2011-10-13 at 11:30 -0400, David Teigland wrote:
> > On Thu, Oct 13, 2011 at 03:41:31PM +0100, Steven Whitehouse wrote:
> > > > cluster4
> > > > . jid from dlm-kernel "slots" which will be assigned similarly
> > > What is the actual algorithm used to assign these slots?
> >
> > The same as picking jids: lowest unused id starting with 0. As for
> > implementation, I'll add it to the current dlm recovery messages.
> >
> Yes, but the current implementation uses corosync to enforce ordering of
> events, so I'm wondering how the dlm will do that after the change.
One node picks it and then tells everyone. In this case the low nodeid
coordinating recovery, and the new data is added to the status messages.
We still rely on agreed ordering of different recovery events, which is
still based on libcpg.
In cluster3 everyone picks the same values independently based on the
ordered events/messages, just because that's how gfs_controld decides
everything.
> > (Frankly, I'd really like to just set jid to nodeid-1. Any support for
> > that? It would obviously add a slight requirement to picking nodeid's,
> > which 99.9% of people already do.)
> >
> The problem is that if you have a cluster with lots of nodes, but where
> each fs is only mounted by a small number of them, we'd have to insist
> on always creating as many journals as there are nodes in the cluster.
yeah
> > Yes we could; I may do that. Returning the error mentioned above becomes
> > less direct. I'd have to overload the jid arg, or add another to indicate
> > the callbacks are enabled.
> >
> Another alternative is just to add a member of the recover_callbacks
> structure which would be a function taking the first and jid as
> arguments and the dlm can call that to pass the into to gfs2.
>
> That way dlm users who don't care about that would just leave those
> functions NULL, for example,
The simplest variation should become evident once I start writing it;
it's hard to predict.
next prev parent reply other threads:[~2011-10-13 16:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 14:20 [Cluster-devel] cluster4 gfs_controld David Teigland
2011-10-13 14:41 ` Steven Whitehouse
2011-10-13 15:30 ` David Teigland
2011-10-13 16:16 ` Steven Whitehouse
2011-10-13 16:49 ` David Teigland [this message]
2011-10-13 20:30 ` Lon Hohberger
2011-10-14 3:53 ` Fabio M. Di Nitto
2011-10-14 9:23 ` Andrew Beekhof
2011-10-13 15:02 ` Masatake YAMATO
2011-10-13 15:33 ` David Teigland
2011-10-13 19:00 ` Masatake YAMATO
2011-10-13 16:17 ` Steven Whitehouse
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=20111013164931.GD6704@redhat.com \
--to=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;
as well as URLs for NNTP newsgroup(s).