Xref: utzoo comp.unix.questions:6231 comp.unix.wizards:7348 comp.arch:4058
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <7544@brl-smoke.ARPA>
Date: 25 Mar 88 09:37:56 GMT
References: <326@ivory.SanDiego.NCR.COM> <7765@apple.Apple.Com> <7533@brl-smoke.ARPA> <4112@vdsvax.steinmetz.ge.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes:
>In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>|Funny, I thought the difference was that RFS is NFS done right.
>RFS allows access to remote devices, NFS does not.

Right, among other aspects of transparency.

>NFS is stateless. RFS is statefull. This might not seem like much,
>but if an RFS disk is mounted on 100 machines, and the server crashes
>and reboots, ....... Well, it just gets very messy.

I don't think so.  The crash does not go undetected; an attempt to
access a remote file while the link is down returns an immediate
error, and when the link comes back up the RFS subsystem straightens
out the bookkeeping.  I forget the details but I once knew them and
they seemed right to me.

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