Date: Thu, 11 Feb 2021 21:54:27 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Alan Somers <asomers@freebsd.org>, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: NFS delegations don't expire after unmounting client Message-ID: <YQXPR0101MB09684A4372F120C3B3FE5BE5DD8C9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAOtMX2h_2zCNpyzOs=SzuohRvLgga=Eip-LJ-7QjJBvwmueLXg@mail.gmail.com> References: <CAOtMX2h_2zCNpyzOs=SzuohRvLgga=Eip-LJ-7QjJBvwmueLXg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Somers wrote:=0A= >I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD= =0A= >12.2-RELEASE server. Today, most of those clients' mounts hung, and their= =0A= >dmesg displayed "nfs: server XXX not responding, still trying".=0A= Usually these messages indicate a networking layer problem.=0A= Next time (or if it still happening), check basic network connectivity.=0A= Also, if any net interface does not handle TSO correctly for an RPC=0A= message near 64Kbytes in size (the nasty one is where the NFS RPC is=0A= less than 64K by less than 14bytes, so when the MAC layer header is=0A= prepended, the total exceed 64K), you can get "stuck" TCP connections.=0A= Most FreeBSD net chip drivers should be fixed for this, but I wouldn't be= =0A= surprised if there are some broken ones out there.=0A= --> Disabling TSO fixes the problem in this case.=0A= =0A= rick=0A= =0A= But one=0A= client kept running fine. nfsdumpstate on the server showed that that=0A= client, and that one only, had 2 delegations. It also had 1 OpenOwner, 1= =0A= Open, and the CB flags set. It was the only client that had CB set. On=0A= the theory that its delegation callbacks weren't working, I tried=0A= unmounting all of its NFS shares. That worked, but to my surprise=0A= nfsdumpstate showed no change! I could see that the lease time recorded in= =0A= /var/run/nfs-stablerestart was 120s, and I must've waited about 30m in all= =0A= before disabling delegations, unmounting everything, and returning to NFS= =0A= v3. So my questions are, what can cause a delegation to linger around long= =0A= after it should've expired, and what else can I do to debug this problem if= =0A= it recurs?=0A= =0A= -Alan=0A= _______________________________________________=0A= freebsd-fs@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB09684A4372F120C3B3FE5BE5DD8C9>