Part 3 of 3 of responses I got since my first summary posting.
From: IN%"fed!m1rcd00@uunet.uu.net" 25-APR-1990 10:17
To: "YATES, JOHN H." <uunet!a.chem.upenn.edu!YATES@uunet.UU.NET>
Subj: NFS options
I picked this up off Sun's dial up information service.
(1-800-477-4768, 1200 or 2400 baud, 7-1-even, account
"guest", no password.) Maybe it will help.
Note that the best you can hope for is for your application
to terminate abnormally and let go of the file. Your users
may be different, but mine would certainly appreciate the
possibility of recovery that comes with hard mounts.
Bob Drzyzgula
Federal Reserve Board
rcd@fed.frb.gov
-------------------------------------------------------------
>Subject: NFS timeouts
>Date: 2 Dec 89 03:24:09 GMT
>
>
> Hard vs. soft mounts on Suns and Pyramids
>
>Following are some notes on what intr, hard and soft mean to an NFS
>client. This information is accurate for UNIX client implementations
>of NFS derived from the NFS/ONC reference port.
>
>An NFS client will timeout a request if the server does not respond in
>some (user specifiable) period. This is coupled with a retransmission
>count and a backoff mechanism on the timeouts to deal with slow
>servers. A server must be able to deal with multiple, duplicate
>requests arising from retries as a result of his tardy responses.
>
>The following is a brief explanation of the timeout strategy for a
>Unix client.
>
>The mount operation allows specifying a timeout value - timeo, and a
>retry value - retrans - the number of retransmissions of the NFS
>operation, and whether the mount is hard or soft. The soft option
>returns an error if the server does not respond (as described below),
>whereas hard says continue the retry request until the server
>responds.
>
>The intr option may be added to modify the the behaviour of hard mounts,
>and allows keyboard interrupts to stop the retransmissions.
>
>These are described in the following pictures.
>
>A normal NFS request (which is successful on the first shot) is
>processed as follows:
>
>
> Client The Ether Server
> ------ --------- ------
>
> NFS ---> ---------> |
> request |
> <------ |
> server | Increasing
> responds | Time
> <--------- |
> Response |
> Client |
> Continues |
> V
>
>The following picture shows timeouts (timeo value is entered
>in tenths of seconds) up to a retry value (4) against an
>unresponsive server:
>
> Client The Ether Server
> ------ --------- ------
>
> NFS ---> - ---------> |
> | request |
> timeo = 7 |
> | |
> NFS ---> - ---------> |
> | request |
> timeo = 14 |
> | | Increasing
> NFS ---> - ---------> | Time
> | request |
> timeo = 28 |
> | |
> NFS ---> - ---------> |
> | request |
> timeo = 56 |
> retrans = 4 | |
> - ---------> |
> request |
> <------- |
> Timeout returned |
> to caller IF SOFT! - A Major Timeout |
> else if HARD or INTR, double |
> timeo and reenter loop. |
> V
>
>A TIMEOUT is registered on the client from NFS only after the timeo
>time has elapsed for the number of retrans retransmissions specified.
>The initial timeo value itself may be dependent on the type of
>operation (write vs. getattr vs. read) in a given NFS client
>implementation. On each retransmission, the timeo value is doubled.
>
>If a server is mounted soft, the timeout is returned to the calling
>procedure or program.
>
>If a server is mounted hard, NFS will backoff (double the current timeo
>value on each major timeout to some maximum) with a new, longer timeo
>value and attempt again for the specified retrans count (with the new
>current timeo value doubled at each retransmission). The initial
>default timeo on entry to each retransmission cycle has a maximum value
>of 30 seconds. The maximum timeo in retransmission sequence has a
>maximum value of 60 seconds. timeo is specified in tenths of seconds.
>
>If the server is mounted intr, this is the same as hard, except that
>on major timeouts (current, aged timeo value times retrans count with
>backoff) a software interrupt may force an error return of timeout
>to the calling procedure or program. In older implementations of NFS,
>an interrupt can only slip in on a major timeout; a request that has
>an aged timeo value with even a small retrans count can take a mighty
>long time indeed to respond when a server is mounted intr. Later
>implementations allow the interrupt to stop retransmissions much sooner.
>
>Sometimes a mount may seem uninterruptable, when in actuality the
>client may have backed off so the window for the interrupt to take
>effect is a long way off, in an older NFS implementation.
>
>Now on soft mounts garbling the data: this is entirely application
>dependent. If applications check their errors on write()'s (mine do :-)
>then they will see the error and will most likely abnormally end. Most
>applications probably do not, so you get intermittent failures, some
>successes, and resulting garbled data. Now what I forget to do is to
>check the return values on close() - where you may see an asynchronous
>error from a previous write() call. This may be where you see writes
>returning OK - but if you check your close(), it will probably fail.
>Remember - the writes to the server a REALLY asynchronous to your
>application given the buffering inherent in UNIX (which exists between
>your application and NFS). The fact that the write returns OK to the
>application, and may later fail (soft mounted) is consistent with
>normal UNIX behaviour for say a failing disk - where the error is
>detected at some time after the write() returns OK to the application
>when the system actually attempt to write the buffer to disk.
>
>That is why the safest bet, for critical data (such as the NFS files
>which represent your ROOT PARTITION for diskless clients), is to hard
>mount the file system. If you like living on the ragged edge, specify
>the intr option on writable partitions - then you have the control as
>to whether or not you'll trash your file writes in process - with the
>same behaviour as if you've interrupted write()'s to a local hard disk.
>An analogy is that mounting hard with the intr option makes your server
>most resemble local hard disk for your applications.
>
>If you mount your active writable filesystems soft, you might consider
>taking up skyjumping for a hobby where you use randomly defective
>parachutes for that certain extra thrill.
>
>Some work is being done for future NFS releases which implements a
>dynamic retransmission algorithmn which would affect the above
>discussion. This is pretty valid for UNIX clients out there now.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT