Remote File Sharing (RFS) - SVR3

[Guy Harris]

(Why is this in comp.bugs.sys5?  I've redirected followups away from there.)

> It appears to me that all the vendors that purchase a license to SVR3 get
> RFS for free with it, and it is ported to SVR3.  
> 
> At a cost of $25,000, plus more for later updates, license fees, and the
> cost of porting it to SVR3, NFS gets prohibitive fast.

1) It already *is* ported to S5R3; ask Lachman Associates about it.

2) Other people seem to have decided that it's not too prohibitive, since
they've signed up for it.

> Also, NFS does not implement the full UNIX file system symantics, so 
> applications do no port as easily (or transparently).  Also, follow
> on charges for NFS versions that will (speculative) get it up to the
> full file system symantics will probably cost even more.

Also, the only transport layer that's supplied with S5R3 is Starlan; no
TCP/IP or ISO protocol implementation comes with S5R3.  (Yes, NFS has been
demonstrated on top of ISO protocols.)  There is an MS-DOS client
implementation of NFS; there is none for RFS.  NFS is supported by non-S5R3
UNIX systems; RFS isn't.

No, you can't access devices over NFS.  (If a diskless machine's root file
system is being accessed over NFS, you don't *want* to access remote devices
over NFS; were NFS ever changed to permit remote device access, there would
need to be an option to indicate whether special files refer to local or
remote devices.  If RFS were ever changed to permit diskless machines, the
same would be true.)  S5-style locking does work with NFS (technically, it's
not part of NFS; locks are managed by a different server).  Forced-append
mode isn't guaranteed to work, because a forced-append write isn't
idempotent.  It does make a "best effort", which amounts to an "lseek" to
the current EOF followed by a write (done within the kernel, so no other
process on the same machine can get in between them).  Some other operations
also aren't idempotent, although a server-side reply cache seems to prevent
this from being a problem (at least in my experience).

On the other hand, I haven't seen how well stateful servers work in an
environment with more servers than a few carefully-administered central
machines.  When I had a disk, I exported the file system containing my home
directory to other machines; I didn't have to worry about re-mounting my
home directory on those machines if I rebooted my machine.  Another machine
I manage is used for development, so it is sometimes rebooted frequently; it
exports an infrequently-used file system to several clients, and it would be
inconvenient if they were forced to remount that file system ever time we
needed to bring up a new kernel on the server.  (It's also convenient not to
have my sessions smashed if a server crashes.)  I would say off the top of
my head that a stateful server *could* reestablish a connection when the
server comes back up, but as far as I know RFS doesn't do so.

In short, you pays your money and you takes your choice.  I see no evidence
that RFS is a clear winner, and I will avoid speculation as I don't have
enough data.