2/3. fstab options for NFS mounts.
2007-12-25 7:13:00
John
From: IN%"fed!m1rcd00@uunet.uu.net" 24-APR-1990 11:15
To: "YATES, JOHN H." <uunet!a.chem.upenn.edu!YATES@uunet.UU.NET>
Subj: Re: SUMMARY: fstab options for NFS mounts
> My solution from suggestions below: (I'm sure more answers will trickle
> in, but unless they offer something not covered below I won't post them,
> thanks all!).
>
> node:/usr1/mlk /usr1/mlk nfs rw,soft,noquota,retry=3,timeo=10,retrans=10,bg 0
>0
> node:/usr2/jkb /jkb nfs rw,soft,noquota,retry=3,timeo=10,retrans=10,bg 0 0
>
> This indeed timed out in a couple minutes for each file system, and did
> not hang during new logins while the other node was down. Now node is up
> and crunching, so one test is all I got, but it looks good! John
>
>
Although I am perhaps doing well at it, I'm not trying to be obnoxious [:-)];
but anyway here is a quote from the mount(8) man page:
> Read-Write vs. Read-Only
> Filesystems that are mounted rw (read-write) should use the hard
> option.
Soft rw mounts got us in trouble in the early days of our network
implementation. Am I missing something?
Bob Drzyzgula
Federal Reserve Board
From: IN%"tony@Canada.Sun.COM" 24-APR-1990 12:20
Subj: re: NFS
John,
It is not recommended that you mount "rw" with "soft" because you can lose
information if the server is unavailable.
Using "bg" will help you only to boot and mount all file systems without
hanging the system.
Using "timeo" would help if you placed a high value in it, along with retry
operation as you already know.
Tony Santos
Sys/Net Admin
suncan!tony@Sun.Com
----- Begin Included Message -----
>From sun-managers-relay@eecs.nwu.edu Tue Apr 24 04:38:50 1990
Sender: sun-managers-relay@eecs.nwu.edu
From: "YATES, JOHN H." <YATES@a.chem.upenn.edu>
Subject: fstab options for NFS mounts
X-Vms-To: SUN-MAN,YATES
I'd like to hear from experts about what NFS options are recommended
for machines that must remain impervious to other machines crashing,
hanging, etc. The ones below have proven not adequate for some reason.
The retry=3 seemed to cure the things when a machine was down when
the reboot occurred, but when a machine crashed (Convex), the up machine
(sun 3/280S) would hang up during new logins, immediately after putting
out /etc/motd. I hate having to change /etc/fstab on multiple machines
(removing NFS mounts for down machines) until they are all up again.
This has required reboots of production machines and simply can't be
tolerated.
/etc/fstab:
machine:/u1 /u1 nfs rw,soft,retry=3 0 0
rw is necessary. It seems that /etc/exports options cannot be causing
the problem.
What is the consensus about using bg mounts? Can they get you into any
trouble under certain circumstances, or not as much as fg mounts?
Would some combination of retrans=N1,timeo=N2 be helpful?
Thanks for the info. I will summarize the results.
John
----- End Included Message -----
From: IN%"lsf@astrosun.TN.CORNELL.EDU" 24-APR-1990 17:54
Subj: Re: SUMMARY: fstab optons for NFS mounts
We've had really bad problems with soft mounts: using the default entries
but soft mounts, a perfectly normal fortran program can be expected to
fairly frequently miss a read or a write to a file. This is especially true
if the server is more than lightly loaded by other clients.
From: IN%"syd@DSI.COM" 24-APR-1990 18:21
Subj: Re: SUMMARY: fstab optons for NFS mounts
Quoting YATES, JOHN H.,
> I'm pretty comfortable with rw,soft unless someone can convince me
> that hard really offers advantages. And perhaps a higher retry now
> that they are in the background.
The retries aren't in the background, the bg means retry the mount
in the background, but once mounted, the rest is in the foreground.
Its only the initial mount that the bg refers to.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or bpa!dsinc!syd FAX: (215) 938-0235
From: IN%"ian@whistler.sfu.ca" 24-APR-1990 19:04
To: YATES@a.chem.upenn.edu
Subj: Re: SUMMARY: fstab optons for NFS mounts
John,
Normally I would agree with you on the rw,soft paramters in /etc/fstab
however I was recently convinced to use rw,hard in the following scenario:
A Sun 4/280 serves quite a few accounts that may freely work on the
Sun, one of several 3/50s, NeXTs, A/UX Macs, etc., and two Silicon
Graphics 4D/240s. My feeling was that the smaller machines would not
miss much if a filesystem disappeared for a short (< 10 minutes) time
and thus rw,soft would not hurt. This was not a good choice for the
SGI 4D/240s however as they are used by a dozen scientists running
FORTRAN programs generating several MB of data per hour. If a filesystem
went missing for even a few seconds a chunk of data would be missing in
the data file, possibly unknown to the scientist and if known very
difficult to detect by visually scanning the file. They would rather
have the FORTRAN process I/O blocked by the rw,hard parameters
than have to throw the whole data set away and start again
Just my two bits worth.
Cheers!
Ian Reddy, UNIX Systems Consultant Internet: Ian_Reddy@cc.sfu.ca
Computing Services, Admin Bldg Rm AD1021 BITNET: USERIGR1@SFU
Simon Fraser University Telephone: (604) 291-3936
Burnaby, B.C. Canada V5A 1S6 Fax: (604) 291-4242
From: IN%"dupuy@cs.columbia.edu" 24-APR-1990 19:14
To: YATES@a.chem.upenn.edu
Subj: SUMMARY: fstab optons for NFS mounts
The retry option (like bg option) is only for mounts, not for NFS operations.
The retrans option is for the NFS operations themselves.
The problem with rw,soft is that you will sometimes get failures even if a
server is up (if it is slow, or the operation takes a long time, like some
things that ranlib does). Also, some programs don't correctly check for errors
on output (especially close or fclose), and this can result in corruption if
the operation timed out (even though the server was up).
@alex
From: IN%"rlk@Think.COM" "Robert L Krawitz" 24-APR-1990 19:47
To: YATES@a.chem.upenn.edu
Subj: SUMMARY: fstab optons for NFS mounts
Date: Tue, 24 Apr 90 17:01 EST
From: "YATES, JOHN H." <YATES@a.chem.upenn.edu>
Several people have pointed out that rw should have hard, not soft
mounts. I don't think I want the tries to continue for days,
(wouldn't retry override this anyway?).
Retry says how many times the (initial) mount should be retried, not how
many times an NFS operation should be.
If it can't reach the machine
within the parameters above, I believe file corruption is likely anyway,
Nope. If the mount is hard, the operation will simply block until the
server comes back. If it's soft, it will time out. That's when you get
corruption. Remember that most programs don't check every write they do
(someone pointed out, who actually checks that printf() succeeds?).
and we might as well stop trying (soft vs. hard).
Depends upon how critical your data is...
I'm pretty comfortable with rw,soft unless someone can convince me
that hard really offers advantages. And perhaps a higher retry now
that they are in the background.
You're confusing apples and oranges. The retry is for the mount; the
soft vs. hard is for NFS operations (read, write, etc.).
From: IN%"kevin@Corp.Sun.COM" 24-APR-1990 19:47
To: "YATES, JOHN H." <YATES@a.chem.upenn.edu>
Subj: Re: SUMMARY: fstab optons for NFS mounts
[ Regarding "Re: SUMMARY: fstab optons for NFS mounts", YATES@a.chem.upenn.edu writes on Apr 24: ]
> I'm pretty comfortable with rw,soft unless someone can convince me
> that hard really offers advantages. And perhaps a higher retry now
> that they are in the background.
Hard doesn't trash files and directories. I just came from a customer
site that lost all their mail and half (~100MB) their work from creeping
corruption due to soft mounts.
Kevin Sheehan
Sun Microsystems
From: IN%"jayl@bit.UUCP" 24-APR-1990 20:09
To: yates@a.chem.upenn.edu
Subj: Re: SUMMARY: fstab optons for NFS mounts
->I'm pretty comfortable with rw,soft unless someone can convince me
->that hard really offers advantages. And perhaps a higher retry now
->that they are in the background.
The hard/soft decision is simple. If you don't care whether an operation
works or not, soft mount is acceptable. Otherwise, hard mount is the only
possible choice.
After some (painful) experience w/soft mounts, the *only* filesystem I would
even consider mounting soft is /usr/man.
Let the mount retry parameter default. The only time this will really come
into play is after a massive power failure (or other system-wide) shutdown.
In this case, you want 'em to keep trying until everybody gets back up.
The first key to making a multiple server environment work is to make a
seperate subdirectory to hold the mount point(s) for each server. I.e,
mkdir /server1/fs1 /server1/fs2 /server2/fs1 /server2/fs2
This will keep otherwise innocent activities like running shell scripts,
running pwd, etc. from trying to stat hung NFS mounts, which is really the
big bugaboo. Nothing you can do about df, though. Do not under any
circumstances allow an NFS mount point to exist at /. Use symlinks if
it must *appear* to be at /.
The second key is to disable quota checking by any means that will work.
The 'rm /usr/ucb/quota; ln -s /bin/true /usr/ucb/quota' trick is simple
and bullet proof. I've never been able to get the noquota mount option
to work.
Just a side comment-- I've been working with a Sun kernel engr on NFS
corruption problems and she was *very* well aware that soft mounts are
junk. Her comment was essentially "Yeah, soft mounts are really a hole in
the protocol, we're seriously considering doing away with them altogether."
From: IN%"Larry.Wake@West.Sun.COM" "Larry Wake" 24-APR-1990 20:14
To: "YATES, JOHN H." <YATES@a.chem.upenn.edu>
Subj: Re: SUMMARY: fstab optons for NFS mounts
Hard really,really offers advantages. If you set soft, and a write
operation fails, and your software doesn't notice the error, you've
just corrupted your application's data. (and when was the last time
*you* wrote code that checked for return values from printf's?)
Unless you're absolutely sure that all code that's going to write to
your nfs mounts is squeaky clean, I'd say go with hard mounts. Setting
"intr" will allow you to manually abort hung operations if you deem
it to be safe.
From: IN%"harker!harker@apple.com" 24-APR-1990 23:21
To: yates@a.chem.upenn.edu
Subj: Re: SUMMARY: fstab optons for NFS mounts
I would vote for hard mounts rather than soft mounts. My experience it that
with a soft mount the write can fail, and unless the application code tests
to see if the write was successful, and take appropriate action if it is not,
then you will suffer from silent data corruption. The way I mount my NFS
partitions is with the hard option and the intr option. This allows a user
to control C a program that gets stuck on a hard mount. The user can then
take the appropriate action as to what to do about possible data
corruption. So my mount would look like:
node:/u1 /u1 nfs rw,hard,intr,noquota,retry=3,timeo=10,retrans=10,bg 0 0
^^^^^^^^^
I hope this helps
RLH
Robert Harker
Harker Systems Sun Sysadmin Consulting
harker@harker.com 1180 Hester Ave
apple!motcsd!harker!harker San Jose, CA 95126
uunet!harker!harker 408-295-6239
From: IN%"harker!harker@apple.com" 24-APR-1990 23:46
To: yates@a.chem.upenn.edu
Subj: PS, background
PS, background only matters when you are first mounting the file system.
If the file server is not available at mount time then the mount is retried
in the background so as not to hang the machine which is booting. After the
file system is mounted background has no effect what so ever. The only file
system I would not use the bg option on is the /usr file system since if
/usr is not available, then the workstation gets kind of warped when it
skips over the mount.
RLH
Robert Harker
Harker Systems Sun Sysadmin Consulting
harker@harker.com 1180 Hester Ave
apple!motcsd!harker!harker San Jose, CA 95126
uunet!harker!harker 408-295-6239
From: IN%"steve%mrc-applied-psychology.cambridge.ac.uk@NSFnet-Relay.AC.UK" "Steve Platt" 25-APR-1990 09:49
To: YATES%a.chem.upenn.edu@NSFnet-Relay.AC.UK
Subj: Re: SUMMARY: fstab optons for NFS mounts
hi - thanks for your summary, its an interesting area!
I'm one who wouldn't like to see rw and soft together ...
we once thought we lost mailboxes from /usr/spool/mail
by letting a vax mess with them by mounting them soft,rw ...
However, I just wanted to check that you knew about "intr"?
We now mount most things either ro,soft OR rw,hard,intr ...
It lets users hit ^C (and wait a minute!) to get out of a tangle:
although I admit its only partially better than getting hung.
Steve Platt
Computer Manager
MRC Applied Psychology Unit
15 Chaucer Road
Cambridge CB2 2EF
Comments
Got something to say?
You must be logged in to post a comment.
