The nfsd default lease time has been changed from 90 seconds to 45
seconds between Linux 4.14 and 4.19 by commit d6ebf5088f09 ("nfsd4:
return default lease period").
After we did an upgrade of a nfs server from 4.14 to 4.19, we noticed
a failing process and dmesg logs "NFS: nfs4_reclaim_open_state: Lock
reclaim failed!" on a client (Linux 4.14.87). The client had the
file system mounted with vers=4.0.
Network trace indicated, that the client continued to use the
90 seconds lease period of the previous server incarnation and
sent RENEWs every 60 seconds (2/3 of 90 seconds). Sometimes the
server answered with NFS4ERR_EXPIRED.
When this happened, the client executed recovery (SETCLIENTID...) but
did non query the server for a new lease_time. So the problem was
persistent even after the first failure.
As an experiment, I've also restarted a server with the lease time
decrement from 90 to 45 seconds, but the grace period fixed to
90 seconds. Now the client got NFS4ERR_STALE_CLIENTID but still did
not query the server for a new lease_time and continued to send RENEWs
in 60 second intervals.
At least for the later case, the RFC say, a client should refetch
the lease_time:
A server may, upon restart, establish a new value for the lease
period. Therefore, clients should, once a new client ID is
established, refetch the lease_time attribute and use it as the basis
for lease renewal for the lease associated with that server.
However, the server must establish, for this restart event, a grace
period at least as long as the lease period for the previous server
instantiation. This allows the client state obtained during the
previous server instance to be reliably re-established.
[ https://tools.ietf.org/html/rfc7530 ]
I understand that a restart with a grace period smaller than the
previous lease time is never save.
Aside from that, is a server restart with a decreased lease time
supposed to be supported by the Linux client? If not, this is kind
of a trap for server upgrades when just relying on the defaults.
Best
Donald
