Xref: utzoo comp.unix.questions:6254 comp.unix.wizards:7374 comp.arch:4085
Path: utzoo!mnetor!uunet!husc6!think!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <4057@bloom-beacon.MIT.EDU>
Date: 26 Mar 88 03:26:02 GMT
References: <326@ivory.SanDiego.NCR.COM> <7765@apple.Apple.Com> <7533@brl-smoke.ARPA> <4112@vdsvax.steinmetz.ge.com> <7544@brl-smoke.ARPA> <25@denali.UUCP>
Sender: root@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 22

In article <25@denali.UUCP> karish@denali.UUCP (Chuck Karish) writes:
>In article <7544@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes:

::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...

:When I've tried this, the attempt to read from an inaccessible NFS
:partition has timed out after two minutes (on a VAX running SULTRIX).

I've seen both results.  On one occasion, when the link went down, 
processes trying to use the link hung forever, waiting for the data 
which never arrived...
The present result (with newer software which has probably been 
considerably modified by MIT's project Athena) when a server goes 
down is a timeout and error message.


   John Carr           "No one wants to make a terrible choice
   jfc@athena.mit.edu   On the price of being free"           -- Neil Peart