Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Oct 2000 01:07:59 +0200 (CEST)
From:      Janko van Roosmalen <janko@compuserve.com>
To:        Andrew BOGECHO <andrewb@cs.mcgill.ca>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: nfs errors
Message-ID:  <Pine.BSF.4.10.10010010011070.1340-100000@parmenides.utp.net>
In-Reply-To: <20000927142839.C23396@cs.mcgill.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <andrewb@cs.mcgill.ca> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10010010011070.1340-100000>