Re: NFS

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Thu, 9 Jul 2009 08:49:53 +0300
Jukka Marin <jmarin%embedtronics.fi@localhost> wrote:

> I'm using TCP for all NFS mounts now.. we'll see if that helps.  It would
> be great if one could get over an NFS problem without the reset button,
> though....

Interestingly I've been using TCP for NFS for a long time (years), yet
lately I tend to often see these (it might be since the
netbsd-4->netbsd-5 upgrade, but I'm not sure.  Since most of the time
this seemed harmless I didn't look into it much until now):

nfs server foo not responding
nfs server foo is alive again

In all cases, the delay between the two is quite short, in the order of
a second or two at most.  Sometimes these are rare and performance
doesn't seem affected much.  However, at other times these occur
non-stop, and performance is greatly reduced, a CVS update from a local
repository mirror mounted via NFS can then take at least three to four
times longer than usual.

I suspected a possible problem with NFS threads being too low, but
increasing client-side vfs.nfs.iothreads sysctl, and number of threads
in nfsd_flags on server-side didn't seem to help (despite top showing
more available threads).

So yesterday I decided to switch to UDP to verify if it's better.
However, after a certain number of hours, all processes on the client
locked in tstile wchan/state and I had to reboot the client.

The problem doesn't seem to be network related, as an ssh
connection to the server keeps working when this happens, as well as
HTTP/FTP to the server and outside.  I see no network interface
diagnostics in dmesg either.  This didn't occur again, but I'll keep
using UDP a bit for now and see how it goes.

Thanks,
-- 
Matt