Trouble: NFS via TCP

S.C.Sprong scsprong at gmail.com
Wed Nov 22 07:29:49 PST 2006


From: "S.C.Sprong" <scsprong at gmail.com>
To: freebsd-stable at FreeBSD.ORG
Subject: Re: Trouble: NFS via TCP
In-Reply-To: <200611091717.kA9HH631005085 at lurza.secnetix.de>
X-Newsgroups: mpc.lists.freebsd.stable,muc.lists.freebsd.stable

In article <200611091717.kA9HH631005085 at lurza.secnetix.de> you wrote:
>Symptom:  As soon as I use the -T option (TCP) with the mount command,
>it simply hangs forever.  If I use the intr/soft flags, I can Ctrl-C
>it after a while, and the mount indeed appears in the output from
>"mount", but any command that tries to access it (e.g. ls(1)) also
>hangs. Even umount(8) hangs.

I've had the same problems and made similar observations.
A few more:

- Running 'tcpdump tcp port 2048' on the NFS server _after_ the client
  is stuck in this state causes a spontaneous reboot of the server.

- Running 'netstat -a' shows that the client is stuck in an endless
  connect-disconnect loop and chews through port numbers.

- It happens with fxp, rl, and sis cards.

- TCP initial window size advertisement doesn't seem to matter.

- While using UDP I may have encountered a similar bus as described
  in NetBSD bugs bin/20663: deadlock in cron(8)


Many reboots later, I solved my problem by disabling the following tweaks
I had in /etc/sysctl.conf for ages:

#vfs.nfs.bufpackets=8
# 20050510: read 16 blocks instead of 8
#vfs.read_max=16
# 20060908: obsolete?
#vfs.nfsrv.gatherdelay_v3=10000

And reverted to the system defaults:

vfs.nfs4.nfsv3_commit_on_close: 0
vfs.nfs.bufpackets: 4
vfs.nfs.nfs_ip_paranoia: 1
vfs.nfs.nfs_directio_allow_mmap: 1
vfs.nfs.nfs_directio_enable: 0
vfs.nfs.clean_pages_on_close: 1
vfs.nfs.nfsv3_commit_on_close: 0
vfs.nfs.access_cache_timeout: 2
vfs.nfsrv.nfs_privport: 1
vfs.nfsrv.commit_miss: 0
vfs.nfsrv.commit_blks: 0
vfs.nfsrv.async: 0
vfs.nfsrv.gatherdelay_v3: 0
vfs.nfsrv.gatherdelay: 10000

Hope this helps,
scs


More information about the freebsd-stable mailing list