Yizhong Zhou wrote:

Hi Gil,

You may want to try 1) forcing tcp (using '-o proto=tcp' on client's mount command); 2) lowering udp transfer size to 8192 (using '-o rsize=8192,wsize=8192' on client's mount command).

We currently use: rsize=8192,wsize=8192,timeo=14,intr on our fstab. I will look into the tcp option

We experienced the hanging problem with Linux clients (mostly 2.4 kernels). Reducing the udp transer size greatly alleviated the problem and forcing tcp further improve the situation. Starting at kernel 2.4.x (forgot what x exactly is), they started to use 32KB as the default udp transfer size. My understanding is that the Linux NFS clients' default buffer size is too small causing lots of packet loss and retransmission. This translates to the hanging and 'nfs server not responding' problem.

Thanks

Yizhong Zhou zhou@mathworks.com, (508) 647-7371 The Mathworks, Inc. 3 Apple Hill Drive, Natick, MA 01760

On Thu, 27 Jan 2005, Gil Freund wrote:

...

Hi,

We have three Debian systems (two with 2.6.x Kernel and one with 2.4) using a NetApp 720 (6.5.3) as an NFS server.

On two occasions in the last two weeks, when one of the Linux hosts tried to mount a file system from the netapp we got the error: Host nono not responding. (nono being the filer name)

From that moment, no action could be preformed from any of the Linux hosts on the netapp. We see not errors in the log files of either the Linux nor the netapp. Other functions (CIFS, NIS and DNS lookups) continue with not issues.

Attempting to stop and start the NFS service on the netapp did not have any effect, neither did rebooting the clients.

The only workaround was rebooting the filer, after which all NFS operations resumed without a problem.

I have started a trace on NFS, but did not get the same hangup yet.

Did anyone encounter a similar situation, or alternatively can advise on where and what to check?

Thanks

Gil