Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.ira.uka.de
Newsgroups: comp.unix.questions
Subject: Re: Robust Mounts
Message-ID: <1402@smurf.ira.uka.de>
Date: 16 Jan 90 21:35:18 GMT
References: <21956@adm.BRL.MIL> <1990Jan9.220629.26976@ee.rochester.edu> <1376@smurf.ira.uka.de> <1990Jan15.202631.3594@ee.rochester.edu>
Reply-To: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Organization: University of Karlsruhe, FRG
Lines: 64

In comp.unix.questions deke@ee.rochester.edu (Dikran Kassabian) writes:
< In article <1376@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes:
< > In article <10284@zodiac.ADS.COM> mliverig@spark.uucp writes:
< > >
< > >1) Soft mounts of read-write file systems would increase the risk of
< > >corrupting the file systems.
< > 
< >How?
< 
< In the same way a system crash can result in corruption of local disks.
< Summary information can be inaccurate depending on exactly when the crash
< takes place, as it relates to pending disk writes.
< 
< An NFS rw,hard mount is a win in this case...  the process on the NFS client
< hangs until the NFS mount becomes available again, and so gets to continue.
< Not that this guarentees you a clean file-system, but I believe that your
< chances are lots better.
< 
Well, I fail to see why, given the following sequence of events
- client sends NFS request
- server (partially or completely) processes the request
- server crashes

either one of the following events
- client times out, user program gets error
or
- client hangs until server is back, user program continues
or
- client gets disconnected by automount until server is back, user program
  gets error

could possibly have any impact on the probability that
- server disk needs to be fsck'd, probably dropping some files
or that
- buffer was not written on server, causing inconsistent database although the
  client got an OK return from NFS.

A hard NFS mount obviously improves your chances if
- server crashes but managed to write its buffers, but
- client was doing things which left the database inconsistent.

In this case, obviously, a hard mount is helpful here and either a soft mount
or a client disconnected by an automount daemon would cause problems because
the client has no way to get the database back into a consistent state.

I hope I'm not missing anything here.
< 
< BUT:
< 
< My preferred solution would be to use SunOS automount(8) or Jan-Simon Pendry's
< 'amd'.  I'm still hoping someone will comment on my question, which
< asked about automounter, and why it might be considered 'not yet safe'.
< 
My understanding of an automount daemon is:
- It periodically tests if the server is still there.
- If not for N seconds, the server is unmounted. This has the same effect as a
  soft mount in that the client, trying to read or write a file, gets an error.
- Any request to the server returns an error immediately until the server is
  back online, in which case
- the automounter reconnects the client to the server.

Anyone more knowledgeable enlighten me in case I'm wrong, please.
-- 
Matthias Urlichs