Xref: utzoo comp.unix.questions:6263 comp.unix.wizards:7383 comp.arch:4092
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!att-ih!ihnp4!inuxc!iuvax!pur-ee!ea.ecn.purdue.edu!davy
From: davy@ea.ecn.purdue.edu (Dave Curry)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <2323@ea.ecn.purdue.edu>
Date: 26 Mar 88 01:19:41 GMT
References: <326@ivory.SanDiego.NCR.COM> <7765@apple.Apple.Com> <7533@brl-smoke.ARPA> <4112@vdsvax.steinmetz.ge.com> <7544@brl-smoke.ARPA>
Reply-To: davy@ea.ecn.purdue.edu.UUCP (Dave Curry)
Organization: Purdue University Engineering Computer Network
Lines: 34

In article <7544@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>If an NFS server reboots, the clients just waits and then continue on.
>
>Typically an attempt to access a file on a down link causes the process
>to BLOCK at UNINTERRUPTIBLE priority!  I have been quite pissed off at
>this, on more than one occasion.  It's great fun to type "df" and then
>find that you're never going to get any farther...

So mount your file systems "hard,intr" and you can interrupt out of
things.  Granted this is not a whole lot better, but you can at least
get your workstation back.  Better yet, if you have the file system
mounted for read-only purposes and seldom actually write anything to it
(e.g. other servers' file systems), then mount them "soft", and the
problem goes away.

The biggest brain damage with NFS in this regard comes in a situation
like, say, you have /usr/server1, /usr/server2, and /usr/server3
mounted "hard", and you serve off server1.  Then even if server3 goes
down, you're screwed the first time namei() is called -- it hangs on
the down server's file system.  So, some server you hardly ever give a
damn about goes down, and you can't execute any commands until it
comes up.  Yuck.  Sun 4.0 supposedly fixes this by having "mount on
reference" file systems.  The release date for Sun 4.0 is May 19 or
thereabouts.

Somehow I think this discussion is never going to get anywhere... there
are lots of valid reasons for stateless servers, and lots of other
valid reasons for stateful servers.  The problem is that each method
solves the deficiencies in the other - neither approach solves all the
problems.

--Dave Curry
Purdue University
Engineering Computer Network