The recommended solution is to use soft, timeo (deciseconds), and retrans options. soft option for mount command should be used if client responsiveness is favored over data integrity. Suppose applications utilizing NFS data can handle the IO error produced by soft mount, than it is ok to use.
Other options like timeo and retrans options can be used to mount NFS share. Make sure that low values can cause create blips in the network and create outages. The value should be such that there is enough time to recover from network outages but still help in client responsiveness.
mount -t nfs -o soft,timeo=650,retrans=2 server:/nfs/share1 /mnt/nfs-share1
Info from man page of NFS about retrans and timeo is given below;
timeo=n The time in deciseconds (tenths of a second) the NFS client waits for a response before it retries an NFS request.
For NFS over TCP the default timeo value is 600 (60 seconds). The NFS client performs linear backoff. After each retransmission the timeout is increased by timeo up to the maximum of 600 seconds.
retrans=n The number of times the NFS client retries a request before it attempts further recovery action. If the retrans option is not specified, the NFS client tries each request three times.
The NFS client generates a `server not responding` message after `retrans1 retries, then attempts further recovery (depending on whether the
hard mount option is in effect).
