topic NFS timeo values in Operating System - HP-UX

NFS timeo values

Dean M. Durant — Thu, 02 Feb 2006 16:40:40 GMT

Hello, when we change the timeo value from default (none specified) to 30, the timeout seems to shorten. Is the default value really 7 and can we set the value to a value greater than 30? If so, what is the limit?
----------------------------------------
From the HP website ( http://docs.hp.com/en/5991-1811/ch02s03.html#bghdijij
)
----------------------------------------
The timeout, in tenths of a second, for NFS requests (read and write requests to mounted directories). If an NFS request times out, this timeout value is doubled, and the request is retransmitted. After the NFS request has been retransmitted the number of times specified by the retrans option (see below), a soft mount returns an error, and a hard mount retries the request. The maximum timeo value is 30 (3 seconds).

Try doubling the timeo value if you see several server not responding messages within a few minutes. This can happen because you are mounting directories across a gateway, because your server is slow, or because your network is busy with heavy traffic.

Re: NFS timeo values

Dave Olker — Thu, 02 Feb 2006 17:17:34 GMT

Hi Dean,

Are you using NFS over UDP or TCP? Timeouts are handled differently based on the transport protocol you're using.

Dave

Re: NFS timeo values

Dean M. Durant — Tue, 07 Feb 2006 08:27:14 GMT

We are using TCP. Although, we would like to learn as much as we can about the impact of this value on both and how we might best adjust this value. Thanks.

Re: NFS timeo values

Dave Olker — Fri, 18 Jun 2021 11:25:47 GMT

Hi Dean,

In my opinion, the timeo option should *never* be used with NFS/TCP mounts.

One of the main benefits of using a reliable transport like TCP is the automatic handling of data that is not responded to in a timely manner. TCP uses sequence and acknowledgement numbers, scaling windows and intelligent backoff algorithms to ensure that if a packet is lost between the client and server systems it will be retransmitted in a very timely fashion - usually based on the calculated round-trip time on the specific connection.

This is a far more accurate and sensible mechanism to use than a hard-coded timeout value.

The timeo mount option was developed in the early days of NFS, when the only supported transport was UDP. Since UDP is inherently unreliable and makes no guarantees of data delivery, any application using UDP (in this case, NFS) needed to be responsible for handling situations where data didn't make it from systemA to systemB. This is why NFS uses a request/reply design, where if a request is sent and not replied to in a reasonable amount of time it is the client's responsibility to resend the request. The thinking was that since UDP didn't guarantee delivery, there was no way to know whether the request ever made it to the destination.

With TCP, the transport protocol is designed to acknowledge the receipt of data, so TCP knows when a request, or a response to that request, has been fully "received" by the remote system. Again, this built-in functionality negates the need for a timeo option.

The *danger* of using a timeo option with NFS/TCP is that it can still affect the overall behavior of an NFS/TCP filesystem, and in most cases will very negatively affect the behavior and performance.

When used with NFS/TCP, the timeo option really means "I don't care how much data has been sent or acknowledged for this request, when my timer pops you will re-send the entire request from the beginning". If the request was something small like a LOOKUP or GETATTR this isn't a big deal. However, when this is a READ or WRITE or READDIRPLUS request where there is potentially 32KB of data (and in the future potentially much more than 32KB of data) in a request or reply packet, this tells the client or server - resend the entire payload.

This can be very damaging to performance - especially in situations where the network or the server is under heavy load. If the network or server is overloaded, this would explain why requests/replies are taking a long time. By using the timeo option and overriding the TCP graceful retransmission algorithms, you can make a bad situation much worse by forcing the systems to re-send chunks of data that had already successfully made it from systemA to systemB - thereby making the network and server even more overloaded.

That's the brief explanation of why I hate the timeo option.

For more details on timeo and the potential negative effects it can have on NFS/TCP, pick up a copy of my book: "Optimizing NFS Performance" published by Prentice Hall.

I also included a discussion of the timeo option in my NFS Performance techcnial paper found here:

http://docs.hp.com/en/1435/NFSPerformanceTuninginHP-UX11.0and11iSystems.pdf

Hope this helps,

Dave

Re: NFS timeo values

Arunvijai_4 — Tue, 07 Feb 2006 11:18:28 GMT

Hello,

This could be helpful,
http://www.unix.org.ua/orelly/networking_2ndEd/nfs/ch18_01.htm

-Arun