All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Frank van Maarseveen <frankvm@frankvm.com>
Cc: Linux NFS mailing list <linux-nfs@vger.kernel.org>
Subject: Re: NFS - lock failover
Date: Mon, 12 Dec 2011 15:48:38 -0500	[thread overview]
Message-ID: <20111212204838.GD20826@fieldses.org> (raw)
In-Reply-To: <20111212203027.GA5068@janus>

On Mon, Dec 12, 2011 at 09:30:27PM +0100, Frank van Maarseveen wrote:
> On Mon, Dec 12, 2011 at 02:56:13PM -0500, J. Bruce Fields wrote:
> > On Fri, Dec 09, 2011 at 11:36:46AM +0100, Frank van Maarseveen wrote:
> > > On Thu, Dec 01, 2011 at 06:24:16PM +0100, Frank van Maarseveen wrote:
> > > > On Thu, Dec 01, 2011 at 07:07:22PM +0200, Pavel A wrote:
> > > > > Hi everyone!
> > > > > 
> > > > > I was trying not to create new topics, but it seems that posting to an
> > > > > old one doesn't bring it up. Here is the original topic I'm referring
> > > > > to: http://comments.gmane.org/gmane.linux.nfs/13108
> > > > > 
> > > > > I'm building an A/A cluster using NFS v3 and local file systems, and
> > > > > looking for
> > > > > efficient ways for failover (for now I have to restart nfs-kernel-server on
> > > > > Takeover node to be able to initiate grace period), so the discussed solutions
> > > > > are very interesting to me.
> > > > > 
> > > > > Now (4 years after) in current nfs-utils packages (v. 1.2.2-4 and later) I can
> > > > > see that the ability to release locks was really implemented and is
> > > > > working well
> > > > > (I mean interfaces /proc/fs/nfsd/unlock_ip and
> > > > > /proc/fs/nfsd/unlock_filesystem),
> > > > > but how about reacquiring locks on the node, share migrates to? - I've been
> > > > > going through various mailing lists and found a lot of discussions on the topic
> > > > > (also dated mainly 2007), but don't seem to find any rpc-based mechanism or
> > > > > interface like /proc/fs/nfsd/nlm_set_grace to do that, was it ever made?
> > > > 
> > > > I've posted a patch some time ago implementing
> > > > /proc/fs/nfsd/relock_filesystem:
> > > > 
> > > > 	http://permalink.gmane.org/gmane.linux.nfs/42360
> > > > 	http://permalink.gmane.org/gmane.linux.nfs/42361
> > > > 	http://permalink.gmane.org/gmane.linux.nfs/42362
> > > 
> > > Can this patch be scheduled for inclusion in mainline (3.3)?
> > 
> > Could you resend and I'll take another look?
> 
> I'll check it again but except for one fuzz it should still apply on
> 3.2-rc. Patch offsets and an incidental fuzz is sometimes informative
> about possible conflict areas. It has been verified on 3.0 and 3.1

Thanks.  It would be helpful to have them resent in any case.

> > But this should really be fixed to handle v4 locks as well.
> 
> Why do you think it doesn't?

The fact that unlock_* doesn't.  Looking at it.... I suppose that
doesn't matter as much on the grace-period starting side.  How much use
does that have on its own?

--b.

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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 17:07 NFS - lock failover Pavel A
2011-12-01 17:24 ` Frank van Maarseveen
2011-12-01 17:34   ` Pavel A
2011-12-01 17:36     ` Pavel A
2011-12-09 10:36   ` Frank van Maarseveen
2011-12-12 19:56     ` J. Bruce Fields
2011-12-12 20:30       ` Frank van Maarseveen
2011-12-12 20:48         ` J. Bruce Fields [this message]

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=20111212204838.GD20826@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=frankvm@frankvm.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.