From owner-freebsd-stable Sat Sep 30 16: 8: 9 2000 Delivered-To: freebsd-stable@freebsd.org Received: from pop.hccnet.nl (pop.hccnet.nl [193.172.127.94]) by hub.freebsd.org (Postfix) with ESMTP id 0400137B66E for ; Sat, 30 Sep 2000 16:08:03 -0700 (PDT) Received: from parmenides.utp.net by pop.hccnet.nl via uds50-123.dial.hccnet.nl [193.173.123.50] with ESMTP id BAA03009 (8.8.5/1.13); Sun, 1 Oct 2000 01:07:55 +0200 (MET DST) Received: from localhost (janko@localhost) by parmenides.utp.net (8.9.3/8.9.3) with ESMTP id BAA01435; Sun, 1 Oct 2000 01:07:59 +0200 (CEST) (envelope-from janko@compuserve.com) X-Authentication-Warning: parmenides.utp.net: janko owned process doing -bs Date: Sun, 1 Oct 2000 01:07:59 +0200 (CEST) From: Janko van Roosmalen X-Sender: janko@parmenides.utp.net To: Andrew BOGECHO Cc: freebsd-stable@FreeBSD.ORG Subject: Re: nfs errors In-Reply-To: <20000927142839.C23396@cs.mcgill.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I know too little of NFS to give expert advice but I have read in several places about problems of Solaris NFS servers with PC UNIX clients. In the past Linux NFS clients used to have problems with Solaris NFS servers. Solaris sent blocks which were larger than Linux could handle The block sizes needed to be downsized which hurt performance badly under some circumstances. From a footnote in the NFS chapter of the "Linux network administrators guide": "* As explained to me by Alan Cox: The NFS specification requires the server to flush each block of data written to disk before it returns an acknowledgment. As BSD kernels are only capable of page-sized writes (4K), writing four chunks of 1K each to a BSD-based NFS server results in four write operations of 4K each" The man page for "mount_nfs" mentions options for readsize and writesize. Maybe you can experiment with them, and see if they have any influence on your problems. ===Janko van Roosmalen - Vught - Netherlands=== On Wed, 27 Sep 2000, Andrew BOGECHO wrote: > > Wed Sep 27 14:17:28 EDT 2000 > > Hi again, > > I honestly don't think that our fileserver is overloaded. In once case > we only have 7-8 clients attached to a server, but we still get those > errors. Plus looking at the nfsstat -s on the server the stats seem > fine. > > fileserver# nfsstat -s > > Server rpc: > Connection oriented: > calls badcalls nullrecv badlen xdrcall dupchecks > 11313781 0 0 0 0 1118618 > dupreqs > 0 > Connectionless: > calls badcalls nullrecv badlen xdrcall dupchecks > 26264056 0 0 0 0 5324484 > dupreqs > 2986 > > Server nfs: > calls badcalls > 37567839 45 > Version 2: (26177393 calls) > null getattr setattr root lookup readlink > 1690545 6% 2709174 10% 504888 1% 0 0% 14019992 53% 112929 0% > read wrcache write create remove rename > 2159210 8% 0 0% 4152388 15% 306474 1% 291492 1% 26167 0% > link symlink mkdir rmdir readdir statfs > 26954 0% 3595 0% 8603 0% 3926 0% 157339 0% 3717 0% > Version 3: (11083347 calls) > null getattr setattr lookup access readlink > 87839 0% 2752555 24% 289734 2% 3428751 30% 3017051 27% 4036 0% > read write create mkdir symlink mknod > 512789 4% 364009 3% 107504 0% 2404 0% 183 0% 0 0% > remove rmdir rename link readdir readdirplus > 102123 0% 1231 0% 38680 0% 26801 0% 69350 0% 185946 1% > fsstat fsinfo pathconf commit > 53989 0% 8381 0% 6990 0% 23001 0% > > Server nfs_acl: > Version 2: (17 calls) > null getacl setacl getattr access > 0 0% 1 5% 0 0% 10 58% 6 35% > Version 3: (307082 calls) > null getacl setacl > 0 0% 307082 100% 0 0% > > The nfs version 2 calls are from linux machines. > > Net stats: > > Name Ipkts Ierrs Opkts Oerrs Colls Coll-Rate > hme0 132658680 0 144411666 0 0 0.00 % > > If it is a problem due to Soalris, are there any fixes? > > Once again, thank you for your time. > > Andrew. > > On Wed, Sep 27, 2000 at 10:43:20AM -0700, Alfred Perlstein wrote: > > * Andrew BOGECHO [000927 10:05] wrote: > > > Wed Sep 27 12:53:48 EDT 2000 > > > > > > Thanks for the speedy reply. > > > > > > In answer to your question. I did try setting: > > > > > > /defaults type:=nfs;opts:=rw,vers=3,proto=tcp,intr,soft,nodevs,nosuid,rsize=8192,wsize=8192; > > > > > > But it made no difference. This error occurs on all our freebsd > > > client machines, as all our fileservers are running Solaris. > > > > > > Does anyone else with Solaris fileservers and FreeBSD clients > > > have such problems? > > > > > > Our /etc/dfs/dfstab file is as follows: > > > > > > share -F nfs -o rw=client-netgroup /mnt1 > > > share -F nfs -o rw=client-netgroup /mnt2 > > > share -F nfs -o rw=client-netgroup /mnt3 > > > share -F nfs -o rw=client-netgroup /mnt4 > > > > Like I said, it looks like the solaris machine is dropping the > > connections, check the utilities on solaris to see how many > > dropped connections you're having and make sure the server isn't > > over loaded. > > > > Also, since you say it doesn't cause any problems, I would leave it > > alone, FreeBSD is particularly picky about slow to respond servers > > and will let you know. > > > > -- > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > "I have the heart of a child; I keep it in a jar on my desk." > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-stable" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message