Re: Issues with NFS RPC

Hope you don't mind a top post.  Although you provided a lot of information,
but I didn't see mention of what version of FreeBSD you are using?

If it is FreeBSD 13.0, then the problem is well known and fixed in stable/13.
(There is also a less common problem that is in older versions of FreeBSD
as well.)

See PR#256280 on bugs.freebsd.org (Comment #2)

If your problem does not appear to be either of these (determined mostly
by the output line of "netstat -a" at the time of the hung client for that
client's connection, please post again or comment on the bug report).

rick


________________________________________
From: owner-freebsd-fs@freebsd.org <owner-freebsd-fs@freebsd.org> on behalf of Adam Stylinski <kungfujesus06@gmail.com>
Sent: Tuesday, July 6, 2021 9:48 AM
To: freebsd-fs@freebsd.org
Subject: Issues with NFS RPC

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca


Hello,

So this may be something somewhat specific to my configuration, but it's
starting to smell like a bug somewhere in NFS's RPC handling (either the
Linux client or the FreeBSD rpcbind).

I have two machines, connected via a 40gbps direct attached link, with
static IPs.  They are leveraging jumbo frames (9000 byte MTU).  The storage
is backed by a healthy zpool.  I can reliably reproduce this issue, but it
takes a long amount of time (it was 40GB worth of packet capture before I
gave up and then the issue finally reappeared).

It seems that after a long enough time frame over an NFSv3 export,
virtualbox hangs my VM that has disks backed over that share.  The rsize
and wsize are 128k to match the maximum stripe size of the pool, and I'm
just using plain old sec=sys, no kerberos involved.  The error I get from
rpcdebug on the Linux client looks as follows:
https://pastebin.com/rCv2ZTri
Error 110 I looked up is a generic timeout.  During this time, when the
server seems to be going deaf to these xids, I can ping the server over the
interface the connection is over.  Traffic flows fine, the NICs are
basically unutilized.  There are no visible errors on any of the
interfaces.  The NICs are ConnectX-3's, running in en mode (ethernet).  I
tried switching to NFSv4, and eventually had the same problem, but with the
added bonus that it never seems to successfully retransmit and hangs in
perpetuity (NFSv3 eventually recovers, after the likely 600 second timeout).

These seem to be fairly reliable NICs, and I don't see anything on the
server or client to indicate that it's a network hardware issue.  Is there
anything I can do to diagnose this on the FreeBSD server end?  It seems
that the Linux kernel's rpcdebug facilities seem to mostly just give a
bunch of noise.

I did manage to run wireshark on the client during this stall period, and I
had noticed some TCP packets that were classified as duplicate ACKs when
the NFS traffic finally turned over again.