Trouble: NFS via TCP

Chris chrcoluk at gmail.com
Wed Nov 22 23:17:44 PST 2006


On 22/11/06, S.C.Sprong <scsprong at gmail.com> wrote:
> 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
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>

good observation all the servers I have had locking up on me with
nfs/sshfs all inicdently use sis/fxp/rl no coincidence the only 2
servers that dont use these lan cards which are using dc/re work fine
with nfs.

Chris


More information about the freebsd-stable mailing list