[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: slow nfs



(Sorry for the funny-style reply, but like I said, I'm not on the list,
so I'm cutting and pasting this out of the web archives to reply - thank
goodness I checked, hmm? ;-)

> recently as in it used to work better?

Ya.  A *lot* better.  There is a huge difference between the hardware
capabilities of the server and the client (client is much more
powerful), but with compiling software on the client over nfs-mounted
directories, it feels slower than my ancient cheap crappy laptop.  ;-)

> what options are you using to mount other then soft/hard?
>
>  my options:
>
> nfsvers=3,rsize=8192,wsize=8192,rw

rw,hard,intr

I didn't set those explicitly, but looking in /proc/mounts, I get :
moonweaver:/home /remote/moonweaver/home nfs rw,v3,rsize=8192,wsize=8192,hard,intr,udp,lock,addr=moonweaver 0 0


> it may be a locking issue, at least on my debian linux(2.2.19) nfs
> server it's really bad at locking, fairly sure it's a debian issue
> as rpc.lockd is what fails(/etc/init.d/nfs-common restart always fixes
> it), rather then a kernel issue. my redhat 7.3 nfs server(2.4.18) works
> better with locking.

> GNOME apps are especially locking intensive, many of them may stall
> if nfs locking is broken.

Well, I'm not mounting it on /home, but in a /remote directory (as you
can see above).  Just as a twist, at work I run a RedHat8(9 as of today)
client with a Debian/Woody server, using the GNOME desktop on NFS
mounted /home, and it's *fast*.

If it is something in the software/kernel packages themselves, then it
would have to be something in Sarge (running on my home server) and not
Woody (work server), or something in the latest Sid packages... I'm
guessing it's much more likely just something screwy in my config
somewhere.

> nate

Thanks for the time taken to help.  ^,^
-- 
Sean Middleditch <elanthis@awesomeplay.com>
AwesomePlay Productions, Inc.



Reply to: