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.
>
>
>
>
next prev parent 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).