[comp.unix.i386] RFS vs. NFS

larry@focsys.uucp (Larry Williamson) (08/16/90)

In article <279@prosun.first.gmd.de> Thomas Hoberg writes:
 > 
 > The flames I just read about ISC's NFS implementation have me wounder
 > why I should use NFS at all. [ ... ]  All we need is some 
 > kind of networking not necessarily NFS. Isn't there a thing called
 > RFS (AT&T's Remote File System) included with ISC? Shouldn't it 
 > actually perform a lot faster than the state-less design of NFS?

Yes, there is RFS. We've been using it with ISC 2.0.2 for about a
year. ISC implemented RFS on top of tcp/ip, so you need tcp/ip. 

The older version of ISC's tcp/ip was buggy to such an extent that it
was possible to crash a machine hourly if you used the network enough.
The latest release seems to have fixed the problems. 

RFS is nice, and it is awful.

RFS is fast. It feels much faster than NFS. The integration of RFS
into Sys V is almost seamless. A file system mounted with RFS is
almost indistinguishable from a local file system, file and record
locking work just nice, remote devices can be accessed this way, a
named pipe on an RFS file system can be used to communicate with a
process on another machine.

RFS is a not as nice to maintain. There are more parts. In an unstable
network it is a nighmare. I can't get clients to remount after a
server reboots with out manual intervention. If a client comes up or
tries to mount a file system that is on a server that is not
available, then you've got trouble. I played with secondary servers
for a while, but that seemed to cause more problems than it solved.

RFS will only work on machines that are System V. No MS-DOS, no VMS,
no BSD, etc, etc.

RFS is wonderful when it is running clean (as it is this week).

NFS is nice, and it is also awful.

NFS is not very fast. The integration of NFS into Sys V is clumsy.
Many functions do not work very well, or at all. Record locking does
not work, a lot of sloppy code that does directory processing by
opening the directory as a file rather than via the directory(3)
functions will not work (some shell's wildcard processing for
example). 

NFS is available for MS-DOS,if you have any dos users, they can mount
unix file systems.

NFS is easy to maintain. Actually it is childs play. 

RFS and NFS can be used together. All our System V machines run both.

Even with the admin headaches, I much prefer RFS when available.

-Larry

peter@ficc.ferranti.com (Peter da Silva) (08/21/90)

For a third choice, Intel's OpenNET software runs on top of an OSI protocol
stack, so you can kiss off TCP/IP, but they do provide support for DOS FS
access. In addition, it's extremely easy to maintain and runs well on an
ether shared with TCP/IP. It includes a concept known as "redirects", which
allow many of the niceties of symbolic links, and you don't have to play
games with remote mounts. Instead a super-root, "//", is created. To access
files on a remote system, you access "//sysname/usr/bin...". You can use
redirects if you want to slide these into your own file system to emulate
remote mounts (say, for /usr/spool/news... though we prefer to access
//xds13/usr/spool/news remotely). Named pipes and all that jazz work fine.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com (currently not working)
peter@hackercorp.com

rcd@ico.isc.com (Dick Dunn) (08/22/90)

peter@ficc.ferranti.com (Peter da Silva) mentions:
> For a third choice, Intel's OpenNET software...
> ...Instead a super-root, "//", is created. To access
> files on a remote system, you access "//sysname/usr/bin..."...

Ugh!  This isn't the first time I've seen this trick, but it's still a bad
idea.  I wish all the clever developers who decided, "Yeah, we can just use
a double / for that!" had been experienced with UNIX before they inflicted
their bright ideas on us.  Using // as magic *breaks* things.  Historically,
extra /'s are ignored in file names.  People use this fact.

The // at the beginning is particularly common; it derives from an idiom
used to allow manipulating either some local subtree or root:

ROOT=<whatever>
...
FILE=$ROOT/usr/bletch/gargle

To play in a subtree, you set ROOT=/usr/myhome/playpen or some such.  When
you're ready to get serious, you set ROOT=/ which gives you FILE=
//usr/bletch/gargle.

(Don't bother telling me of the various ways to avoid the problem; I know.
Nor preach to me about standards; I'm talking about existing practice:-)
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...Are you making this up as you go along?

pim@cti-software.nl (Pim Zandbergen) (08/22/90)

peter@ficc.ferranti.com (Peter da Silva) writes:

>Instead a super-root, "//", is created. To access
>files on a remote system, you access "//sysname/usr/bin...". 

Does this mean the root directory has an entry with a slash
in its name ? Sound quite illegal to me.
-- 
Pim Zandbergen                            domain : pim@cti-software.nl
CTI Software BV                           uucp   : uunet!mcsun!hp4nl!ctisbv!pim
Laan Copes van Cattenburch 70             phone  : +31 70 3542302
2585 GD The Hague, The Netherlands        fax    : +31 70 3512837

peter@ficc.ferranti.com (Peter da Silva) (08/23/90)

In article <1990Aug21.183615.8315@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
> peter@ficc.ferranti.com (Peter da Silva) mentions:
> > For a third choice, Intel's OpenNET software...
> > ...Instead a super-root, "//", is created. To access
> > files on a remote system, you access "//sysname/usr/bin..."...

> Ugh!  This isn't the first time I've seen this trick, but it's still a bad
> idea.  I wish all the clever developers who decided, "Yeah, we can just use
> a double / for that!" had been experienced with UNIX before they inflicted
> their bright ideas on us.  Using // as magic *breaks* things.  Historically,
> extra /'s are ignored in file names.  People use this fact.

In practice, however, it breaks very few things. HDB UUCP is about the only
one I can think of, and people who let folks UUCP at random into their
entire network are just asking for trouble. More importantly, this has
become a common usage and is explicitly blessed by P1003.

I more or less agree that there are better choices: I like Futurenet's
"/../machine-name" super-root syntax. But in practice it works. You really
do need to use a name that can't be confused with an actual file name
if you want to avoid the remote-mount business, and "//" or "/../" certainly
serve that purpose. Either of them can confuse a sufficiently "smart"
program that "knows" that "//" and "/../" are really "root".

> To play in a subtree, you set ROOT=/usr/myhome/playpen or some such.  When
> you're ready to get serious, you set ROOT=/ which gives you FILE=
> //usr/bletch/gargle.

Which works just fine. OpenNET allows that unless you're sufficiently
daft to have a system on your network named "usr".

> (Don't bother telling me of the various ways to avoid the problem; I know.

There isn't a problem.

> Nor preach to me about standards; I'm talking about existing practice:-)

Me too.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

peter@ficc.ferranti.com (Peter da Silva) (08/24/90)

In article <1990Aug22.162555.10343@cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes:
> peter@ficc.ferranti.com (Peter da Silva) writes:
> >Instead a super-root, "//", is created. To access
> >files on a remote system, you access "//sysname/usr/bin...". 

> Does this mean the root directory has an entry with a slash
> in its name?

No, namei recognises the string "//" as a special case (as it does
for "/" now) and looks up the system name in an internal table. If
it doesn't find it, it strips the leading slash and tries again.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

michael@fts1.uucp (Michael Richardson) (08/28/90)

In article <1990Aug21.183615.8315@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
>> For a third choice, Intel's OpenNET software...
>> ...Instead a super-root, "//", is created. To access
>> files on a remote system, you access "//sysname/usr/bin..."...
>
>Ugh!  This isn't the first time I've seen this trick, but it's still a bad
>idea.  I wish all the clever developers who decided, "Yeah, we can just use
>a double / for that!" had been experienced with UNIX before they inflicted

  I much prefer /../sysname/usr/bin. I think this idea first appeared in 
edition 8. It prevents introducing new tokens. 
  I think getwd() (/bin/pwd) breaks for this, but I think that is it.
  If getwd() is in a shared library, then no problem fixing it.

-- 
   :!mcr!:            |  'Golf sucks anyway --- give the land to the
   Michael Richardson |    Indians'  --- recent CANACHAT comment.
 Play: mcr@julie.UUCP Work: michael@fts1.UUCP Fido: 1:163/109.10 1:163/138
    Amiga----^     - Pay attention only to _MY_ opinions. -   ^--Amiga--^

seckin@sumac.intel.com (Seckin Unlu) (08/29/90)

# # For a third choice, Intel's OpenNET software...
# # ...Instead a super-root, "//", is created. To access
# # files on a remote system, you access "//sysname/usr/bin..."...
# 
# Ugh!  This isn't the first time I've seen this trick, but it's still a bad
# idea.  I wish all the clever developers who decided, "Yeah, we can just use
# a double / for that!" had been experienced with UNIX before they inflicted
# their bright ideas on us.  Using // as magic *breaks* things.  Historically,
# extra /'s are ignored in file names.  People use this fact.

Too late; There are thousands of XENIX/UNIX (including System V R3.2)
systems out there that have been running OpenNET for up to 6 years 
(and none of them report any application breaking; applications should
not be manipulating path names, except for the last file name anyway).

 -- It's configurable, default is '//', use 'NW' or '``' if you want to
 -- It is used only when you have to specify a full path name
 -- With the redirector, some users never specify full network names
 -- The '//' or whatever delimiter, would give OpenNET software the
    first attempt in resolving a path name - not a last chance.
 
# ROOT=<whatever>
# ...
# FILE=$ROOT/usr/bletch/gargle
# 
# To play in a subtree, you set ROOT=/usr/myhome/playpen or some such.  When
# you're ready to get serious, you set ROOT=/ which gives you FILE=
# //usr/bletch/gargle.
# 
# (Don't bother telling me of the various ways to avoid the problem; I know.
# Nor preach to me about standards; I'm talking about existing practice:-)
# -- 
# Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
#    ...Are you making this up as you go along?

In resolving //usr/bletch/garble, OpenNET would get the first shot,
and if there is a node named "usr" in your trusted subnetwork, then
the path name refers to /bletch/garble on that node.  Otherwise, if
there is an alias "usr" for some node on the LAN, that is if you have
explicitly made a network connection using "usr" for an alias, then
the path name refers to /bletch/garble on that node.  Otherwise, the
path name will be resolved by the local kernel.

So, if you don't have funny names like usr, bin, etc for your nodes
on your (small) trusted subnetwork, or if you have not used funny
names like usr, bin, etc for your aliases, there won't be any conflicts.

# #Instead a super-root, "//", is created. To access
# #files on a remote system, you access "//sysname/usr/bin...". 
# 
# Does this mean the root directory has an entry with a slash
# in its name ? Sound quite illegal to me.
# -- 
# Pim Zandbergen                            domain : pim@cti-software.nl
# CTI Software BV                           uucp   :
uunet!mcsun!hp4nl!ctisbv!pim
# Laan Copes van Cattenburch 70             phone  : +31 70 3542302
# 2585 GD The Hague, The Netherlands        fax    : +31 70 3512837

No, the root directory has no special entries; The "super-root" is only
conceptual.  Instead the XENIX/UNIX kernels have several OpenNET hooks.
For path name resolution, you would have one in namei().

One thing that's real nice with OpenNET is that there is no problem
accessing the devices (tape, floppy, etc.) of other nodes, as long
as you have the proper access of course.  You can do a straight cpio
to the exotic DAT that your buddy has, over the network.

A big disclaimer:  I'm speaking up as a user only (and a happy one);
I have not been involved with the design or development of OpenNET.

Seckin Unlu            uunet!littlei!seckin  or  seckin@littlei.intel.com
Software Engineer                                 seckin@sumac.intel.com
Intel Corporation

dstailey@gnu.ai.mit.edu (Doug Stailey) (09/02/90)

In article <1990Aug21.183615.8315@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
>peter@ficc.ferranti.com (Peter da Silva) mentions:
>> For a third choice, Intel's OpenNET software...
>> ...Instead a super-root, "//", is created. To access
>> files on a remote system, you access "//sysname/usr/bin..."...
>
>Ugh!  This isn't the first time I've seen this trick, but it's still a bad
>idea.  I wish all the clever developers who decided, "Yeah, we can just use
>a double / for that!" had been experienced with UNIX before they inflicted
>their bright ideas on us.  Using // as magic *breaks* things.  Historically,
>extra /'s are ignored in file names.  People use this fact.
>[...deleted stuff...]
>(Don't bother telling me of the various ways to avoid the problem; I know.
>Nor preach to me about standards; I'm talking about existing practice:-)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

POSIX says that multiple slashes collapse into one slash, so standards
are on your side too.  Apollo's Domain OS is the first place that I
saw the "//" stuff.  They want to be POSIX complient, so they recently
changed one of their rules to say that more that two slashes will
collapse.  But I want to see this go away completely.  I think that
Sun's "automounter" is a much better approach.  It accomplishes the
same stuff that the super-root does and it doesn't break existing
code.
--
Oops, I seem to have misplaced my .signature...