Date: Sun, 29 Oct 2017 18:11:41 +0300 From: Yuri Pankov <yuripv@gmx.com> To: Rick Macklem <rmacklem@uoguelph.ca>, freebsd-current <freebsd-current@freebsd.org> Cc: Stephen Hurd <shurd@FreeBSD.org> Subject: Re: NFSv3 issues with latest -current Message-ID: <790d22eb-e04d-3bc7-0e79-e01feedd4267@gmx.com> In-Reply-To: <YTOPR0101MB2172093DDDCB04687D83DA49DD580@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM> References: <9ceeafa5-cb7f-cb82-db07-de6f28b209e2@gmx.com> <YTOPR0101MB2172093DDDCB04687D83DA49DD580@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Oct 2017 13:13:31 +0000, Rick Macklem wrote:
> Yuri Pankov wrote:
>> All file operations (e.g. copying the file over NFSv3 for me) seem to be
>> stuck running the latest -current (r325100). Reverting just the kernel
>> to r323779 (arbitrary chosen) seems to help. I noticed the "Stale file
>> handle when mounting nfs" message but I don't get the "stale file
>> handle" messages from mount, probably as I'm not running any linux clients.
> These kinds of problems are usually related to your net interface device
> driver or the TCP stack.
>
> A couple of things to try:
> - Disable TSO (look for a sysctl with "tso" in it).
> - Try using mount options rsize=32768,waize=32768 to reduce the I/O
> size. Some device drivers don't handle long chains of mbufs well,
> especially when the size is near 64K.
> (These issues have been fixed in current, but if a bug slips into a net driver
> update or ???)
> - Look at recent changes to the net device driver you are using and try reverting
> those changes if you can do so.
> - Capture packets and look at them in wireshark (which knows NFS) and see
> what is going on the wire.
>
> There hasn't been any recent changes to NFS that should affect NFSv3 mounts
> or to the kernel rpc, so I doubt the NFSv4.1 changes would be involved.
Thanks for the hints, Rick!
Indeed, it was one of the changes to sys/dev/e1000, reverting just the
commit made everything look normal again (CC'ing the author).
The NIC is:
igb0@pci0:2:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82576 Gigabit Network Connection'
class = network
subclass = ethernet
Interface configuration (note the MTU):
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
options=e525bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:25:90:72:54:22
inet6 fe80::225:90ff:fe72:5422%igb0 prefixlen 64 scopeid 0x1
inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
And the commit itself:
commit f81cb8df32ae96299b8bbc2e948c17ad3aab59ca
Author: shurd <shurd@FreeBSD.org>
Date: Sat Sep 23 01:33:20 2017 +0000
Some small packet performance improvements
If the packet is smaller than MTU, disable the TSO flags.
Move TCP header parsing inside the IS_TSO?() test.
Add a new IFLIB_NEED_ZERO_CSUM flag to indicate the checksums need
to be zeroed before TX.
Reviewed by: sbruno
Approved by: sbruno (mentor)
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D12442
Notes:
svn path=/head/; revision=323941
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?790d22eb-e04d-3bc7-0e79-e01feedd4267>