NFS Performance Tuning for HP-UX 11.0 and 11i Systems

nfs performance tuning for hp-ux 11.0 and 11i systems page 99

Notes:

Page 99July 22, 2002

nfs/udp

vs.

nfs/tcp

Why would an NFS client need to

retransmit a request?

• The client is unable to send the request (i.e. resource exhausted)

• The request is dropped on the network before arriving on the server

• The server is down or a network partition has occurred

• The request arrives on the server but the server’s socket is full

• The server receives the request but cannot process it in time

• The server is unable to reply to the client (i.e. resource exhausted)

• The reply is dropped on the network before it arrives on the client

• The client is unable to receive the reply (i.e. resource exhausted)

Because NFS was originally designed to only use UDP as a network transport, and

because of the semantics of UDP (i.e. unreliable, connectionless), NFS was

designed with its own built-in mechanisms to guarantee data integrity. The client

keeps track of the requests it sends and waits for a response from the server before

generating new requests. If the client does not receive a response from the server

within a given time period, it considers the original request lost and reissues the

request. The number of times the client will retry the request depends upon whether

the NFS mount uses hard-mount or soft-mount semantics, where hard mounts will

continually retry the request until a response is received, and soft mounts will

eventually time out the request and return control (and any error) to the application.

There are many reasons an NFS client would be forced to resend data. The most

common scenarios are listed above. The point of this list is to illustrate the number

of places in a typical NFS client/server relationship where a request or reply can

be lost, necessitating a retransmission.