nfs client/server? FYI

Darin Perusich Darin.Perusich at cognigencorp.com
Fri Jan 24 10:27:48 EST 2003


hello,

in researching this issue i've come across an annoying and potentially 
dangerous nfs problem when you have a solaris nfs server and the stock 
redhat7.3 kernel. this has also been documented with the redhat 7.1, 7.2 
and some 6.x releases. i initially thought that the UID/GID's was my 
problem, it's actually not. those with a sunsolve.sun.com support 
account can check out bug id# 4764852 for more details.

when performing any substantial I/O on the nfs mount the system locks 
up, floods the network with nfs traffic, which causes massive packet 
lose to all hosts the network. any machine that has the same nfs share 
mounted will start spitting errors simliare to "kernel: nfs: task 354 
can't get a request slot". the client system does not recover until 
rebooted.

i've found a few ways to work around this problem. upgrade the kernel to 
the latest version avialable from redhat. mount the filesystems with 
specific rsizes and wsizes, values of 8192, 4096 seem to work without 
problems. 8192 is the default value and the max for nfs over udp. a 
value of 16k over upd is not valid but still works. it's NOT specifying 
these values that causes the problems.

i know that there are people on the list that have linux and solaris 
mixed in their environments and i thought this might come in handy.

darin.

Robert Meyer wrote:
> Hmmm... that sounds familiar.  First of all, 4294967294 is actually
> FFFFFFFE in hex.  That works out to -1 or -2 (I forget) if we're
> talking about a signed integer.  A lot of systems used to use -1
> as user nobody so I would check to see if you're remapping nobody
> to -1 in your exports file.  A note from the Linux 'exports' man page:
>        By  default,  exportfs  chooses  a uid and gid of -2 (i.e.
>        65534) for squashed access. These values can also be over­
>        ridden  by  the anonuid and anongid options.  Finally, you
>        can map all user requests to the anonymous uid by specify­
>        ing the all_squash option.
> 
> Sounds like it might have something to do with what you have there.
> 
> Cheers!
> 
> Bob
> 
> --- Darin Perusich <darinper at cognigencorp.com> wrote:
> 
>>hello,
>>
>>i'm mounting an nfs filesystem to a redhat7.3 box from a solaris8 
>>fileserver and i'm seeing some wierd uid's and gid's. files that are 
>>owned by user nobody have uid/gid of 4294967294, nobody on both systems 
>>are setup like "nobody:x:60001:60001:Nobody:/:/sbin/noshell".
>>
>>has anyone ever seen this before?
>>
>>-- 
>>Darin Perusich
>>Unix Systems Administrator
>>Cognigen Corp.
>>darinper at cognigencorp.com
>>
>>
> 
> 
> 
> =====
> Bob Meyer
> Knightwing Communications, Inc.
> 36 Cayuga Blvd
> Depew, NY 14043
> Phone: 716-308-8931 or 716-681-0076
> Meyer_RM at Yahoo.com
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 


-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corp.
darinper at cognigencorp.com





More information about the nflug mailing list