Article 40283 of comp.sys.sun.admin:
Path: mri-gw!psinntp!psinntp!psinntp!gatech!howland.reston.ans.net!EU.net!sun4nl!fwi.uva.nl!not-for-mail
From: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: comp.sys.sun.admin
Subject: Re: mount -t nfs -o soft,rw ...
Date: 3 Jun 1995 15:22:14 +0200
Organization: FWI, University of Amsterdam
Lines: 34
Distribution: world
Message-ID: <3qpnm6$51a@mail.fwi.uva.nl>
References: <1995Jun2.162954.23318@hrbicf>
NNTP-Posting-Host: mail.fwi.uva.nl

kma@icf.hrb.com (Kirk Anderson) writes:

>What are the drawbacks and/or gotchas to performing an NFS mount with the
>options of BOTH 'soft' and 'rw'?   Or with 'hard', 'rw', and 'bg'?

If you value your data, *never* use "soft".  Soft can corrupt data
on reading (or bail out in the middle of a transfer) and writing.
You may use soft for "ro" if you yourself want to restart the failed
transfers.

The problem with soft mounts is that it may indicate failures to
early.  If the server is bogged down, is rebooting or if tehre is
a short lived network failure, you  don't want to fail.
But you can never chose the timeout big enough so you can be certain
that there is a true failure or not.

>If the 'bg' option could play a role, please enlighten me.  The way the man
>page reads, the _mount_ will retry in the background, however, the manner
>of NFS requests is unclear.  If the NFS request ran in the background, what
>would be returned to the NFS client application during that time?


My preffered option combination is: hard,intr,bg (for non-crucial but
directly mounted fses.)  ng is not needed for automounted mounts.

intr will enable your users to kill/interrupt processes that hang on
downed servers.

Casper
-- 
Casper Dik - Network Security Engineer - Sun Microsystems
This article is posted from my guest account at the University
of Amsterdam.  My real-life e-mail address is: Casper.Dik@Holland.Sun.COM
Opinions expressed here are mine (but you're welcome to share them with me)