NFS delegations don't expire after unmounting client

[Rick Macklem]

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".  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?
The FreeBSD NFSv4 server implements "courtesy locks" (my idea, but someone
else coined the term for it), where a lock is not thrown away until both the
lease has expired and a conflicting lock request is received from another client.
--> In this case, that would be an Open of the file from another client.
The idea is to avoid loss of lock state when there is a networking partitioning
that exceeds the lease duration.

When a client dismounts, it should tell the server it is done with the open/lock
state by doing a DestroyClientID operation. (SetClientID/SetClientIDConfirm for 4.0)
--> If the Linux client did this, then it sounds like something is broken in the server,
      but my hunch is that the Linux client did not do this.
If you can capture packets during a dismount, you should be able to look
at them in wireshark and see if the DestroyClientID happened.

There is also the nfsrevoke command, which is supposed to be able to
get rid of client lock state, but I'll admit I haven't tested it in like a decade;-)

Maybe courtesy locks should be made optional, but they have never
caused problems and I'd have to look at the code to see if that can
easily be done. Might need to do so as another "make the broken Linux
client work" sysctl;-). They are now the defacto standard, you know;-)

rick

-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"