Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Sep 2000 14:28:39 -0400
From:      Andrew BOGECHO <andrewb@cs.mcgill.ca>
To:        freebsd-stable@FreeBSD.ORG
Subject:   Re: nfs errors
Message-ID:  <20000927142839.C23396@cs.mcgill.ca>
In-Reply-To: <20000927104320.Z9141@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Sep 27, 2000 at 10:43:20AM -0700
References:  <20000927093713.D13245@cs.mcgill.ca> <20000927090805.R9141@fw.wintelcom.net> <20000927130420.A23396@cs.mcgill.ca> <20000927104320.Z9141@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000927142839.C23396>