Xref: utzoo comp.unix.questions:6233 comp.unix.wizards:7349 comp.arch:4059
Path: utzoo!mnetor!uunet!yale!cmcl2!arizona!lm
From: lm@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <4496@megaron.arizona.edu>
Date: 25 Mar 88 08:49:47 GMT
References: <326@ivory.SanDiego.NCR.COM> <7765@apple.Apple.Com> <7533@brl-smoke.ARPA> <4112@vdsvax.steinmetz.ge.com>
Reply-To: lm@megaron.arizona.edu.UUCP (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 27

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

Yeah, well, I've worked on Suns (NFS:"stateless") and Apollos
(???:stateful), and quite frankly, I prefer the Apollo version, in
principle, at least.  Here's why:  Although the performance of NFS is
initially better (much better) it degrades very poorly, to the point of
being unusable.  The Apollo version starts out slow but seems to
degrade linearly (or close to linearly) with pressure.  Now, I don't
know if the state-less/ful aspects of the designs had anything to do
with this, but I suspect it comes into play.

And a further comment on stateless file systems:  when working on the
Apollos, it was rarely, if ever the sort of disaster envisioned by the
stateless advocates when a node crashed.  I dunno how, but somehow or
other things seemed to work ok.  You noticed that certain trees of
files were "gone".  That's all.  Nothing worse.
-- 

Larry McVoy	lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm