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