NFS delegations don't expire after unmounting client

[Rick Macklem]

Alan Somers wrote:
>On Thu, Feb 11, 2021 at 2:54 PM Rick Macklem wrote:
>>Alan Somers wrote:
>>>I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD
>>>12.2-RELEASE server.  Today, most of those clients' mounts hung, and their
>>>dmesg displayed "nfs: server XXX not responding, still trying".
>>Usually these messages indicate a networking layer problem.
>>Next time (or if it still happening), check basic network connectivity.
>>Also, if any net interface does not handle TSO correctly for an RPC
>>message near 64Kbytes in size (the nasty one is where the NFS RPC is
>>less than 64K by less than 14bytes, so when the MAC layer header is
>>prepended, the total exceed 64K), you can get "stuck" TCP connections.
>>Most FreeBSD net chip drivers should be fixed for this, but I wouldn't be
>>surprised if there are some broken ones out there.
>>--> Disabling TSO fixes the problem in this case.
>
>In fact it is still happening.  Basic network connectivity works.  But tcpdump shows almost no network activity.  Just >a few keepalive packets of length 0-1.  Based on the fact that unmount and even lsof hang on the client, I'm >suspecting a Linux bug somewhere.
Yea, without a packet capture being done when the failure first occurs, it is pretty hard
to diagnose.
There is some way to turn on debugging output in Linux NFS, but I've forgotten how to do it.

As an aside, delegations are rarely useful and make the protocol more complex,
including the need for callbacks to work correctly (in NFSv4.1, they normally
use the same TCP connection as the regular RPCs).
- You might just want to disable them on the server. (You must have set the sysctl non-zero,
   since they are disabled by default).

Have fun with it, rick

-Alan