NFS issues since upgrading to 13-RELEASE

[Jason Unovitch]

Olav,

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.

Jason

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
> Message-ID:
>         <CAJ7kQyGQrxe7wJs+MezErdNUoLE1HEvD6ixiu2W5=
> 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
> FreeBSD
> > 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,
> and
> > as far as I can tell it's not a disk or network I/O issue. I'll get
> several
> > "nfs: server not responding, still trying" messages on the client and a
> few
> > minutes later it usually recovers. It's not clear to me yet what's
> causing
> > 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
> vmstat,
> > 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,
> because
> > 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
> Norway
> Phone: +47 918 000 59
>