Path: utzoo!attcan!uunet!lll-winken!ames!haven!mimsy!tank!shamash!com50!mscunx!moria!tdh
From: tdh@moriaMoria.Sp.Unisys.Com (Thomas Hintz)
Newsgroups: comp.dcom.lans
Subject: Re: NFS vs RFS
Summary: Different approaches
Message-ID: <340@moriaMoria.Sp.Unisys.Com>
Date: 11 Jan 89 16:56:13 GMT
References: <9018@cit-vax.Caltech.Edu> <7387@chinet.chi.il.us> <437@aurora.AthabascaU.CA>
Organization: Unisys: CSI Engineering, Eagan MN
Lines: 28

In article <437@aurora.AthabascaU.CA>, rwa@auvax.uucp (Ross Alexander) writes:
> In article <7387@chinet.chi.il.us>, Leslie Mikesell writes:
> > I've only used RFS but as I understand things RFS preserves the unix
> > semantics to a greater extent than NFS.
> 
> Agreed.  But, sadly, the implementations I have used (RFS over
> WIN/TCP, 10B5 network, AT&T 3B2/600's) are slower than molasses in

Sun sells NFS as a stateless remote file system protocol over a lightweight,
unreliable transport (UDP).  File locking, mounting facilities are there too.

AT&T sells everyone on a statefull protocol that implements full semantics
running over a reliable transport (TCP).

The NFS UDP transport implementation is optimistic that data packets get to
their destination most of the time anyway, so the recovery in bad transmissions
is in NFS.  Their assertions prove true in most small LANs, so they get great
performance.  NFS crash recovery is also very simple because no states can get
lost.

The RFS TCP transport implementation incurs more overhead on every packet
to ensure reliability, plus RFS incurs a lot of overhead in the way it
implements the UNIX semantics and crash recovery.

Personal conclusions:  NFS performs better in reliable LANs where tight UNIX
filesystem semantics aren't required, but RFS may perform better in unreliable
networks or where tight UNIX semantics are required.  Also, administration of
an NFS network is a hell of a lot simpler.