All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 5/5] gfs2: dlm based recovery coordination
Date: Tue, 20 Dec 2011 14:16:43 -0500	[thread overview]
Message-ID: <20111220191643.GB12136@redhat.com> (raw)
In-Reply-To: <1324377548.2723.7.camel@menhir>

On Tue, Dec 20, 2011 at 10:39:08AM +0000, Steven Whitehouse wrote:
> > I dislike arbitrary delays also, so I'm hesitant to add them.
> > The choices here are:
> > - removing NOQUEUE from the requests below, but with NOQUEUE you have a
> >   much better chance of killing a mount command, which is a fairly nice
> >   feature, I think.
> > - removing the delay, which results in nodes often doing fast+repeated
> >   lock attempts, which could get rather excessive.  I'd be worried about
> >   having that kind of unlimited loop sitting there.
> > - using some kind of delay.
> > 
> > While I don't like the look of the delay, I like the other options less.
> > Do you have a preference, or any other ideas?
> > 
> Well, I'd prefer to just remove the NOQUEUE command in that case, so
> that we don't spin here. The dlm request is async anyway, so we should
> be able to wait for it in an interruptible manner and send a cancel if
> required.

I won't do async+cancel here, that would make the code unnecessarily ugly
and complicated.  There's really no reason to be so dogmatic about delays,
but since you refuse I'll just make it block, assuming I don't find any
new problems with that.

> > > Again - I don't want to add arbitrary delays into the code. Why is this
> > > waiting for half a second? Why not some other length of time? We should
> > > figure out how to wait for the end of the first mounter recovery some
> > > other way if that is what is required.
> > 
> > This msleep slows down a rare loop to wake up a couple times vs once with
> > a proper wait mechanism.  It's waiting for the next recover_done()
> > callback, which the dlm will call when it is done with recovery.  We do
> > have the option here of using a standard wait mechanism, wait_on_bit() or
> > something.  I'll see if any of those would work here without adding too
> > much to the code.
> > 
> Ok. That would be a better option I think.

Only if it doesn't make things more (unnecessarily) complex.

Dave



  reply	other threads:[~2011-12-20 19:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 22:03 [Cluster-devel] [PATCH 5/5] gfs2: dlm based recovery coordination David Teigland
2011-12-19 13:07 ` Steven Whitehouse
2011-12-19 17:47   ` David Teigland
2011-12-20 10:39     ` Steven Whitehouse
2011-12-20 19:16       ` David Teigland [this message]
2011-12-20 21:04         ` David Teigland
2011-12-21 10:45           ` Steven Whitehouse
2011-12-21 15:40             ` David Teigland
2011-12-22 21:23     ` David Teigland
2011-12-23  9:19       ` Steven Whitehouse
2011-12-19 15:17 ` Steven Whitehouse
2012-01-05 15:08 ` Bob Peterson
2012-01-05 15:21   ` David Teigland
2012-01-05 15:40     ` Steven Whitehouse
2012-01-05 16:16       ` David Teigland
2012-01-05 16:45 ` Bob Peterson
2012-01-05 16:46 David Teigland
2012-01-05 16:58 ` Steven Whitehouse
2012-01-05 17:13   ` David Teigland
2012-01-09 16:36 ` Steven Whitehouse
2012-01-09 16:46   ` David Teigland
2012-01-09 17:00     ` David Teigland
2012-01-09 17:04       ` Steven Whitehouse
2012-01-09 17:02     ` 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=20111220191643.GB12136@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 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.