Re: grace-period ending & NLM

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Aug 07, 2015 at 07:10:58AM -0400, Jeff Layton wrote:
> On Thu, 6 Aug 2015 21:02:34 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> 
> > On Thu, Aug 06, 2015 at 06:24:42PM -0400, Jeff Layton wrote:
> > > On Thu, 6 Aug 2015 16:23:36 -0400
> > > bfields@fieldses.org (J. Bruce Fields) wrote:
> > > 
> > > > We have two grace periods, one for NLM and one for NFSv4+, and don't
> > > > permit normal locking until both are over.
> > > > 
> > > > As far as I can tell nfsdcltrack doesn't understand statd/NSM state; it
> > > > only concerns itself with NFSv4+.  It can end the NFSv4 grace period
> > > > early, but that still leaves the server returning GRACE errors until NSM
> > > > exits its grace period.
> > > > 
> > > > The server has never had any smarts to end the NSM grace period early,
> > > > even though there are common cases (e.g., no clients at all) where it
> > > > easily could.  We could fix that.
> > > > 
> > > 
> > > Erm...but it does have those smarts. statd should end the grace period
> > > early if there were no clients to be notified when it starts. That's
> > > done by writing to /proc/fs/lockd/nlm_end_grace. Those patches were
> > > merged upstream in the kernel and nfs-utils around the same time as the
> > > other early grace lifting patches.
> > 
> > Yeah, I don't know how I forgot that.  Thanks for the reminder.  That
> > doesn't seem to be working for me on Fedora 21.  I'll take another look.
> > 
> > (I may still apply ths patch if you don't see a problem with it.)
> > 
> > --b.
> > 
> 
> No objection. I think it looks reasonable.
> 
> I'd also be interested to know why the NLM grace period isn't being
> lifted early for you. That did work when I tested it last.
> 
> Oh, and I misstated earlier...it's not statd that lifts the grace
> period early, it's sm-notify. sm-notify is in charge of notifying hosts
> after a reboot and if it has none to notify it'll write "Y" to that file
> (if it exists).

Yes, sorry, and I just wasn't running the test right: sm-notify only
gets run on a real reboot.  (nfs-server.service does start it, but it
exits immediately if it sees the pid file it wrote before).  Adding
SMNOTIFYARGS='-f' to /etc/sysconfig/nfs makes this work as expected.

(In my defense, that's kind of weird behavior: but as I understand it
statd lumps together all clients and servers on the same machine, so a
a notify would cause us to lose locks on any nfs mounts?  In which case
maybe this is the only safe thing to do.)

--b.