NFS delegations don't expire after unmounting client
Rick Macklem
rmacklem at uoguelph.ca
Thu Feb 11 21:54:30 UTC 2021
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.
rick
But one
client kept running fine. nfsdumpstate on the server showed that that
client, and that one only, had 2 delegations. It also had 1 OpenOwner, 1
Open, and the CB flags set. It was the only client that had CB set. On
the theory that its delegation callbacks weren't working, I tried
unmounting all of its NFS shares. That worked, but to my surprise
nfsdumpstate showed no change! I could see that the lease time recorded in
/var/run/nfs-stablerestart was 120s, and I must've waited about 30m in all
before disabling delegations, unmounting everything, and returning to NFS
v3. So my questions are, what can cause a delegation to linger around long
after it should've expired, and what else can I do to debug this problem if
it recurs?
-Alan
_______________________________________________
freebsd-fs at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
More information about the freebsd-fs
mailing list