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