NFS issues since upgrading to 13-RELEASE
jason.unovitch at gmail.com
Sat Apr 17 13:23:49 UTC 2021
Does anything change if you set -tso -lro on the serving NIC on your
FreeBSD server side? Do the Linux clients remain responsive then?
I had seen something similar with a Ubuntu 20.04 client going to a
13.0-CURRENT/STABLE server but chalked it up to it starting around the time
of the last Chelsio firmware update. I haven't had the time to dig into it
and the temporary triage of setting '-tso -lro' at boot hasn't been as
temporary as I hoped. That did stable it up on my side. Curious what you
see and if that helps add another data point to understanding the issue.
On Fri, Apr 16, 2021 at 1:30 AM <freebsd-current-request at freebsd.org> wrot
> Date: Thu, 15 Apr 2021 21:07:18 +0200
> From: Olav Gjerde <olav at backupbay.com>
> To: Allan Jude <allanjude at freebsd.org>
> Cc: freebsd-current at freebsd.org
> Subject: Re: NFS issues since upgrading to 13-RELEASE
> irDNg2mOA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> I have the same issue, using Ubuntu 20.10 with Linux 5.8 kernel. The Linux
> NFS client will get unresponsive and it does not recover in my case, even
> if I restart NFS on FreeBSD. I upgraded from FreeBSD 12.1-RELEASE though.
> On Thu, Apr 15, 2021 at 8:36 PM Allan Jude <allanjude at freebsd.org> wrote:
> > On 4/15/2021 9:22 AM, Chris Roose wrote:
> > > I posted this in -questions and someone suggested I post here as well.
> > >
> > > I'm having NFS availability issues between my Proxmox client and
> > server (10G link) since upgrading to 13-RELEASE. And unfortunately I
> > upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of
> > stuck.
> > >
> > > Periodically, the NFS server (I've tried both v3 and v4.2 clients) will
> > go unresponsive for several minutes. I never had this problem on 12.2,
> > as far as I can tell it's not a disk or network I/O issue. I'll get
> > "nfs: server not responding, still trying" messages on the client and a
> > minutes later it usually recovers. It's not clear to me yet what's
> > the block. Restarting nfsd on the server will resolve the issue if it
> > doesn't clear itself.
> > >
> > > Any pointers for troubleshooting this? I've been looking through
> > gstat, top, etc. when the problem occurs, but I haven't been able to
> > pinpoint the issue. I can get pcap, but it would be from the hosts,
> > I don't have a 10G tap or managed switch.
> > >
> > run `nfsstat -d 1` and try to capture a few lines from before, during,
> > and after the stall, and that may provide some insight.
> > Specifically, does the queue length grow, suggesting it is waiting on
> > the I/O subsystem, or does it just stop getting traffic all together.
> > --
> > Allan Jude
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe at freebsd.org"
> Kind Regards / Med Vennlig Hilsen
> Olav Gr?n?s Gjerde
> BackupBay Gjerde
> Madlaforen 35
> 4042 HAFRSFJORD
> Phone: +47 918 000 59
More information about the freebsd-current