linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bruce Fields <bfields@fieldses.org>
To: Marc Eshel <eshel@us.ibm.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: grace period
Date: Fri, 1 Jul 2016 16:07:42 -0400	[thread overview]
Message-ID: <20160701200742.GA24269@fieldses.org> (raw)
In-Reply-To: <OF82A5FFDC.3CCEBF40-ON88257FE3.0059C174-88257FE3.00604E03@notes.na.collabserv.com>

On Fri, Jul 01, 2016 at 10:31:55AM -0700, Marc Eshel wrote:
> It used to be that sending KILL signal to lockd would free locks and start 
> Grace period, and when setting nfsd threads to zero, nfsd_last_thread() 
> calls nfsd_shutdown that called lockd_down that I believe was causing both 
> freeing of locks and starting grace period or maybe it was setting it back 
> to a value > 0 that started the grace period.

OK, apologies, I didn't know (or forgot) that.

> Any way starting with the kernels that are in RHEL7.1 and up echo 0 > 
> /proc/fs/nfsd/threads doesn't do it anymore, I assume going to common 
> grace period for NLM and NFSv4 changed things.
> The question is how to do IP fail-over, so when a node fails and the IP is 
> moving to another node, we need to go into grace period on all the nodes 
> in the cluster so the locks of the failed node are not given to anyone 
> other than the client that is reclaiming his locks. Restarting NFS server 
> is to distractive.

What's the difference?  Just that clients don't have to reestablish tcp
connections?

--b.

> For NFSv3 KILL signal to lockd still works but for 
> NFSv4 have no way to do it for v4.
> Marc. 
> 
> 
> 
> From:   Bruce Fields <bfields@fieldses.org>
> To:     Marc Eshel/Almaden/IBM@IBMUS
> Cc:     linux-nfs@vger.kernel.org
> Date:   07/01/2016 09:09 AM
> Subject:        Re: grace period
> 
> 
> 
> On Thu, Jun 30, 2016 at 02:46:19PM -0700, Marc Eshel wrote:
> > I see that setting the number of nfsd threads to 0 (echo 0 > 
> > /proc/fs/nfsd/threads) is not releasing the locks and putting the server 
> 
> > in grace mode.
> 
> Writing 0 to /proc/fs/nfsd/threads shuts down knfsd.  So it should
> certainly drop locks.  If that's not happening, there's a bug, but we'd
> need to know more details (version numbers, etc.) to help.
> 
> That alone has never been enough to start a grace period--you'd have to
> start knfsd again to do that.
> 
> > What is the best way to go into grace period, in new version of the
> > kernel, without restarting the nfs server?
> 
> Restarting the nfs server is the only way.  That's true on older kernels
> true, as far as I know.  (OK, you can apparently make lockd do something
> like this with a signal, I don't know if that's used much, and I doubt
> it works outside an NFSv3-only environment.)
> 
> So if you want locks dropped and a new grace period, then you should run
> "systemctl restart nfs-server", or your distro's equivalent.
> 
> But you're probably doing something more complicated than that.  I'm not
> sure I understand the question....
> 
> --b.
> 
> 
> 
> 

  reply	other threads:[~2016-07-01 20:07 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 21:25 [PATCH] NFS: Don't let readdirplus revalidate an inode that was marked as stale Trond Myklebust
2016-06-30 21:46 ` grace period Marc Eshel
2016-07-01 16:08   ` Bruce Fields
2016-07-01 17:31     ` Marc Eshel
2016-07-01 20:07       ` Bruce Fields [this message]
2016-07-01 20:24         ` Marc Eshel
2016-07-01 20:47           ` Bruce Fields
2016-07-01 20:46         ` Marc Eshel
2016-07-01 21:01           ` Bruce Fields
2016-07-01 22:42             ` Marc Eshel
2016-07-02  0:58               ` Bruce Fields
2016-07-03  5:30                 ` Marc Eshel
2016-07-05 20:51                   ` Bruce Fields
2016-07-05 23:05                     ` Marc Eshel
2016-07-06  0:38                       ` Bruce Fields
     [not found]                 ` <OFC1237E53.3CFCA8E8-ON88257FE5.001D3182-88257FE5.001E3A5B@LocalDomain>
2016-07-04 23:53                   ` HA NFS Marc Eshel
2016-07-05 15:08                     ` Steve Dickson
2016-07-05 20:56                       ` Marc Eshel
     [not found]         ` <OF5D486F02.62CECB7B-ON88257FE3.0071DBE5-88257FE3.00722318@LocalDomain>
2016-07-01 20:51           ` grace period Marc Eshel
     [not found] <4F7F230A.6080506@parallels.com>
     [not found] ` <20120406234039.GA20940@fieldses.org>
2012-04-09 11:24   ` Grace period Stanislav Kinsbursky
2012-04-09 13:47     ` Jeff Layton
2012-04-09 14:25       ` Stanislav Kinsbursky
2012-04-09 15:27         ` Jeff Layton
2012-04-09 16:08           ` Stanislav Kinsbursky
2012-04-09 16:11             ` bfields
2012-04-09 16:17               ` Myklebust, Trond
2012-04-09 16:21                 ` bfields
2012-04-09 16:33                   ` Myklebust, Trond
2012-04-09 16:39                     ` bfields
2012-04-09 16:56                     ` Stanislav Kinsbursky
2012-04-09 18:11                       ` bfields
2012-04-10 10:56                         ` Stanislav Kinsbursky
2012-04-10 13:39                           ` bfields
2012-04-10 15:36                             ` Stanislav Kinsbursky
2012-04-10 18:28                               ` Jeff Layton
2012-04-10 20:46                                 ` bfields
2012-04-11 10:08                                 ` Stanislav Kinsbursky
2012-04-09 23:26     ` bfields
2012-04-10 11:29       ` Stanislav Kinsbursky
2012-04-10 13:37         ` bfields
2012-04-10 14:10           ` Stanislav Kinsbursky
2012-04-10 14:18             ` bfields

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=20160701200742.GA24269@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=eshel@us.ibm.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 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).