Path: utzoo!utgpu!attcan!lsuc!eci386!woods
From: woods@eci386.uucp (Greg A. Woods)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Summary: a network transparent filesystem
Keywords: GNU OS features kernel fun! network transparent filesystem
Message-ID: <1989Jun6.000120.14888@eci386.uucp>
Date: 6 Jun 89 00:01:20 GMT
References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <338@arc.UUCP> <7439@bsu-cs.bsu.edu> <1989May26.224924.5293@eci386.uucp> <209@sopwith.UUCP>
Reply-To: woods@eci386.UUCP (Greg A. Woods)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 80

In article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes:
> In article <1989May26.224924.5293@eci386.uucp> woods@eci386.UUCP (That's ME) writes:
> 
> | Second, a leading '//' with a special meaning is a tremendous KLUDGE!
> | It's even worse than "machine_A:/"!
> 
> Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge.
> Your syntax attaches special to another character.  With the // syntax,
> the special chars remain limited to / and null.

I see '//' as a huge kludge, 'cause it special-cases the meaning
of two consecutive slashes when they appear at the beginning of a
line.  This goes directly against the understood meaning of
consecutive slashes (i.e. scrunch them into one slash).

The "mach_A:/" at least identifies this syntax as a kludge (to the
eye, and the machine).  Besides, using a second character is
better than overloading an already used one.

Of course I don't like either syntax.  I want to be able to put
directory hierarchies anywhere I please, whether they are on a
remote machine, or local.  That's part of what network tranparency
for filesystems is all about.  The meaning of "mounting a
filesystem" should be exactly the same, be it a local mount of a
physically local disk, or a remote mount of a filesystem
advertised to the network.

Further in article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes:
> Why do you want to have to mount somebody else's filesystem on your
> system just to be able to access it?  It's already mounted on their
> system.  All you need is a way to get to it.

Cause if I'm on a metropolitan sized network (> 1000 machines), I
don't want 1000 root directories!  But that's only a tiny part of it.

The way to get into some filesystem is to mount it.  It doesn't
matter where that filesystem physically resides.  This is part of
filesystem semantics.

Besides, I don't want to have to make my entire filesystem
available to the network.  I may want to make all of some local
mount (i.e. partition) available, or I may want to make an entire
directory hierarchy (other than root) available, and I don't want
the ability to make all of my filesystem available.  One way to do
this by advertising a directory name to the network as available
to be mounted remotely.  I may want to be able to put a password
on this capability too, perhaps in conjunction with some form of
authentication service like Kerberos(sp?).

Even further in article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes:
> One additional requirement I forgot to list in my previous article
> is that remote devices must be as transparent as regular files.
> Some inferior network filesystems break the "a file is a file is a file"
> rule.

Of course.  That's another aspect to transparency.  RFS goes to
great lengths not to break filesystem semantics (and so far as I
can see, it succeeds).

The entire concept of network transparency to filesystem semantics
is of utmost importance.  If attention is not paid to this aspect,
of an operating system, the result will be another huge pile of
kludges.

PS:  I had hoped, given the forum, that I wouldn't have to "waste"
bandwidth talking about this stuff in detail.  However, if one
person responds in such a way to indicate I didn't get my point
across, I'd guess there are at least 10 more who didn't get it
either.  Anyway, I don't mind stating my humble opinion!  :-)
No offense intended Snoopy!

PPS:  I should hope this discussion is not only serving to clarify
a few points, but to also provide some input to those people who
want to work on the GNU design and implementation.
-- 
						Greg A. Woods

woods@{{utgpu,eci386,ontmoh,tmsoft}.UUCP,gpu.utcs.UToronto.CA,utorgpu.BITNET}
+1-416-443-1734 [h]  +1-416-595-5425 [w]		Toronto, Ontario CANADA