Xref: utzoo comp.unix.questions:6238 comp.unix.wizards:7353 comp.arch:4068
Path: utzoo!mnetor!uunet!steinmetz!davidsen
From: davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <10105@steinmetz.steinmetz.ge.com>
Date: 25 Mar 88 16:11:31 GMT
References: <326@ivory.SanDiego.NCR.COM> <7765@apple.Apple.Com> <7533@brl-smoke.ARPA> <4112@vdsvax.steinmetz.ge.com>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 27

In article <4112@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes:
| [...]
| 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.
| 
| If an NFS server reboots, the clients just waits and then continue on.

  I think this is a case of apples and oranges... NFS clearly is faster
than RFS at this time because of stateless operation and caching. RFS
knows about opens and locks and stuff, ideal for operation when geting
it right is better than getting it fast.

I think that NFS has minimal problems when used to share files for read
only (which is a lot of what we do here) and single user access. I would
be much more confident that RFS wouldn't bite me if I were running a
database application. I think there are times when you need to know that
the server has gone away, to be positive that the locks are locked and
the data is/isn't current.

I know that people are running database access through RPCs with a
single server process, but the need to do that somewhat proves my point.
Each method has its advantages, and people should understand them.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me