Subject: Re: [nfsv4] What is a reasonable minimum lease time?

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 10 Jan 2019 14:53:42 -0500

On Sat, Dec 29, 2018 at 10:56:36PM +0000, Rick Macklem wrote:
> J. Bruce Fields wrote:
> >Don't you also need to know how much state in total needs to be
> >recovered?  The typical server probably doesn't know how much state its
> >average client has to recover.  I suppose it could set some upper
> >bounds.
> True. However the server does know if client(s) are still doing Reclaim type
> open/lock operations.
> 
> A long time ago I did some testing with the BSD (not yet in FreeBSD) server I had,
> where I had 100 clients each holding many locks (can't remember how many) and
> then I would reboot the server and the clients weren't able to reclaim all the locks
> within the 2minute grace period I had set.
> 
> I fixed the problem by having the server extend the grace period until it no longer
> saw any Reclaim open/lock operations within the last 1/2 lease duration (or
> something like that, I haven't looked at the code for a lonnngggg time).
> This seems to work ok, but does require that the initial grace period be long
> enough for all clients to reconnect and start doing Reclaim open/lock
> operations before the grace period ends.
> When I reported this on this mailing list, I think that inspired the addition of
> Reclaim_complete to NFSv4.1?
> 
> For NFSv4.0, I think the grace period can be greater than the lease duration, if the
> server implementor chooses to do so.
> (The FreeBSD server uses a default lease duration of 2minutes and this can only
>  be changed by editing/recompiling the code so no one can choose absurd values
>  for it easily.)

That might be a good idea.  It also means you don't have to worry about
handling lease-time changes correctly.  Though I do like the fact that I
can set it to a few seconds and get through my reboot regression tests
in less time....

As I said Linux knfsd's current policy is to wait a lease period, then
extend the grace period an additional second for each second that
there's a reclaim operation, up to a maximum of one additional lease
period.

I don't have any attachment to those exact parameters (yours might be
better), but I like the idea of extending the grace period dynamically,
so the client's main responsibility is just to make sure it can get to
that first reclaim operation in time and then do the rest as quickly as
it can.

--b.