Part 2 of 3 of responses I got since my first summary posting.
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
rcd@fed.frb.gov
From: IN%"tony@Canada.Sun.COM" 24-APR-1990 12:20
To: yates@a.chem.upenn.edu
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
To: sun-managers@eecs.nwu.edu
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
yates@a.chem.upenn.edu
----- End Included Message -----
From: IN%"lsf@astrosun.TN.CORNELL.EDU" 24-APR-1990 17:54
To: YATES@a.chem.upenn.edu
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
To: YATES@a.chem.upenn.edu
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-0235From: 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
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT