cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: Groupd uevent clean up
Date: Fri, 28 Nov 2008 11:07:56 +0000	[thread overview]
Message-ID: <1227870476.9571.237.camel@quoit> (raw)
In-Reply-To: <20081125170820.GA26746@redhat.com>

Hi,

On Tue, 2008-11-25 at 11:08 -0600, David Teigland wrote:
> On Tue, Nov 25, 2008 at 04:44:32PM +0000, Steven Whitehouse wrote:
> > > OK, thanks, I dislike the const sprinkling, and I don't care about string
> > Whats wrong with adding the consts? It seems to make sense to mark the
> > fsname as const since its just being used as a key for looking up the
> > mg.
> 
> The PITA factor outweighs it's advantages, at least in the code I have to
> maintain myself.
> 
> > My dev machine currently has a strange mix of F-9 and (old) rawhide
> > packages on it, so that installing the required bits of openais to build
> > isn't so easy. If you are able to run a quick test, that would be
> > helpful otherwise, I'll look for another place to build it for testing.
> 
> I'll test a new patch that's limited to the parsing change.
> 
> > I've just noticed dlm_controld has this same bug,
> 
> Fixed that one too.
> 

So I think this needs looking into some more... I've pushed patches to
the tree which send more useful information with the uevents so that we
can avoid reading the sysfs files in many cases, in future. Each uevent
from gfs[2]/lock_dlm now includes:

LOCKTABLE=<clustername:fsname>
LOCKPROTO=[lock_dlm|lock_nolock]

to avoid all the messy parsing of the initial event string. Also I've
added come further information to the two "change" events, so that we
now have:

FIRSTMOUNT=Done

when the first mounter has finished and:

JID=<journal_id>
RECOVERY=[Done|Failed]

when recovery has finished. Is there anything else that is useful I
wonder, while I'm adding new items here? I think I've covered the
important bits anyway.

So I need to revise the initial patch a bit in order to take into
account the new information,

Steve.




  reply	other threads:[~2008-11-28 11:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25 14:08 [Cluster-devel] Groupd uevent clean up Steven Whitehouse
2008-11-25 15:47 ` [Cluster-devel] " David Teigland
2008-11-25 16:44   ` Steven Whitehouse
2008-11-25 17:08     ` David Teigland
2008-11-28 11:07       ` Steven Whitehouse [this message]
2008-12-01 15:28         ` David Teigland
2008-12-01 15:34           ` 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=1227870476.9571.237.camel@quoit \
    --to=swhiteho@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).