Reg NFS Client-server connectivity

[Kaps_2]

Hi All,

What is the default time when the nfs client checks for the nfs server and reestablishes the connectivity with the nfs server if there is any nfs client-server disruption?

[Danny Petterson - DK]

You can set it when you mount the share:


from man 1M mount_nfs:


timeo=n
Set the NFS timeout to n tenths of a second. The default value is 11 tenths of a second for connectionless transports, and 600 tenths of a second for connection-oriented transports.

Greetings
Danny

[rariasn]

Hi,

Two mount command options, timeo and retrans, control the behavior of UDP requests when encountering client timeouts due to dropped packets, network congestion, and so forth. The -o timeo option allows designation of the length of time, in tenths of seconds, that the client will wait until it decides it will not get a reply from the server, and must try to send the request again. The default value is 7 tenths of a second. The -o retrans option allows designation of the number of timeouts allowed before the client gives up, and displays the Server not responding message. The default value is 3 attempts. Once the client displays this message, it will continue to try to send the request, but only once before displaying the error message if another timeout occurs. When the client reestablishes contact, it will fall back to using the correct retrans value, and will display the Server OK message.

If you are already encountering excessive retransmissions (see the output of the nfsstat command), or want to increase the block transfer size without encountering timeouts and retransmissions, you may want to adjust these values. The specific adjustment will depend upon your environment, and in most cases, the current defaults are appropriate.



rgs

[Vijaykumar_1]

>What is the default time when the nfs client checks for the nfs server

-->This was set by the kernel default value.

You can set it manually using similar entry in /etc/fstab.

# volume mount point type options
nfsserver:/dir1 /dir1 nfs timeo=14,intr

[Dave Olker]

Hi,

> What is the default time when the nfs
> client checks for the nfs server and
> reestablishes the connectivity with the
> nfs server if there is any nfs client-
> server disruption?

The NFS client code never "checks for the nfs server" on its own. The client only communicates with the NFS server if an application/process/thread on the client requests an NFS resource.

By default, the TCP connection established between the NFS client and server will be dropped if there is no activity. Since all NFS activity between a single client and a single server goes over a single TCP connection (by default), regardless of how many NFS filesystems are mounted from the server, all of the NFS activity between the client and server would need to be idle for this connection to be torn down.

This does NOT mean the filesystem will be unmounted (unless you're using AutoFS), but the underlying TCP connection between the two systems will be disconnected.

There are two timers that control how long an NFS/TCP connection must be idle before it is disconnected - one on the client and one on the server. The client side timer is controlled by the kctune parameter "rpc_clnt_idle_timeout" and it defaults to 5 minutes. The server-side timer is controlled by the kctune parameter "rpc_svc_idle_timeout" and it defaults to 6 minutes. The client timer is intentionally less than the server because we want the client to be the one to declare the connection idle and drop it.

Regardless of which side drops the connection, the NFS mountpoints remain on the client. As soon as there is any activity on those NFS mountpoints a new TCP connection will automatically be established between the client and server.

As for the "timeo" option, I always recommend leaving that timer alone for TCP filesystems. This timer makes sense to tune in UDP environments, but I'd much prefer to have TCP handle my data retransmission chores since it's built into the protocol. By default the timeo option is 60 seconds for NFS/TCP filesystems, and I suggest leaving it that way. If there is data to be retransmitted, let TCP handle it.

Regards,

Dave