Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!bellcore!iscp.Bellcore.COM!jona
From: jona@iscp.Bellcore.COM (Jon Alperin)
Newsgroups: comp.unix.aix
Subject: Re: Control NFS exported filesystems
Message-ID: <1991Jun19.162331.25505@bellcore.bellcore.com>
Date: 19 Jun 91 16:23:31 GMT
References: <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun19.154830.17276@uai.com>
Sender: usenet@bellcore.bellcore.com (Poster of News)
Reply-To: jona@iscp.Bellcore.COM (Jon Alperin)
Organization: Bell Communications Research (Bellcore)
Lines: 47

In article <1991Jun19.154830.17276@uai.com>, mrl@uai.com (Mark R. Ludwig) writes:
|> In article <8567@awdprime.UUCP>, marc@ekhomeni (Marc Wiz) writes:
|> >In article <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU>,
|> >CALT@SLACVM.SLAC.STANFORD.EDU writes:
|> >> By exprience, I learned that mounting NFS filesystems by the
|> >> hard/foreground options may cause the machines hanging, while
|> >> by the soft/backgroud options seems to work OK.
|> >>
|> >
|> >To put it mildly this is not a good thing to do.  Remember if you mount the
|> >filesystem soft the client process will get an error after three
|> >retries.  If your
|> >application can handle this fine but I have to wonder how many applications
|> >can not.  If you care about your data I recommend hard mounts.  At least when
|> >the server/network comes back up the data will be written/read to/from
|> >the server.
|> 
|> I agree fully.  At least one of the Sun administration manuals states
|> it bluntly: if you are mounting the NFS read/write, you should mount
|> it hard.  To do otherwise is to risk corrupted files.  However, I
|> believe if you have *very* intelligent applications manipulating the
|> files, you may disregard this warning, but I dare say the average Unix
|> utility is not in this category.  Furthermore, why would you want
|> this?  Since your application probably really wants to write the file
|> it was trying to write when the server went silent, then your
|> application has to keep trying until the server responds.  With
|> ``hard'' the system does it for you.

	Hey...maybe this explains the reason that when I save a file
under VI which is kept on another NFS partition, VI tells me that it
was able to save the file, but because the real physical disk was full I
end up with a 0 length file (and lose all my work).....

|> -- 
|> INET: mrl@uai.com       UUCP: uunet!uaisun4!mrl       PSTN: +1 213 822 4422
|> USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA  90293
|> WANT: Succinct, insightful statement to occupy this space.  Inquire within.

-- 
Jon Alperin
Bell Communications Research

---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674
---> UUNET: uunet!bcr!jona

* All opinions and stupid questions are my own *