Re: Network performance

Aaron Ucko (UCKO@vax1.rockhurst.edu)
Sat, 29 Jun 1996 16:18:02 -0600 (CST)

> I've never worked with an Apollo, but I seem to recall seeing variant
> links on NeXTs over AFS last summer. I'll grant that they're a nice
> feature, but they're not strictly compatible with normal symlinks; any
> link to a file with $ in its name would be broken.
>
>I used to work quite a bit with Apollo's and Domain/OS, and I still miss some
>of its features. I also found the variant links to be especially useful. The
>only case that was treated specially was $(VAR) in a name; if the $ did not
>include the matching (VAR) then it did not have special meaning. I don't think
>you'll find very many uses of $(VAR) in symlinks; it's a worthwhile trade-off,
>in my view.

Perhaps it is, but if symlinks are specified by POSIX (and I think they are)
than variant symlinks are non-POSIX by that technicality.

>[discussion of type managers omitted]
>
> Interesting concept, but it looks as if it could have a fair amount of
> overhead.
>
>Not really.

Oh? Either they'd be built into the kernel and make it larger (which I
seriously doubt Linus would endorse) or they would have to run in userspace
and be launched whenever a "virtual" file was accessed, which would have
non-negligible overhead AFAIK, so in that case one might as well go whole
hog with userfs wrt this and not add to kernel code.

> Come to think of it, both of these ideas should be implementable in userfs,
> so no kernel changes are strictly necessary.
>
>There was relatively little or no kernel support for this on the Apollo either.
>The kernel itself had no notion of read/write for disk files. All disk I/O was
>done through memory mapping and then reading/writing the memory. This includes
>access to files anywhere in the network, since demand paging of virtual memory
>mapped from any object in the network was implemented at the heart of the OS.
>You could boot a node to the equivalent of single user mode and then peruse and
>manipulate its file system from another node.
>
>Domain/OS used shared global libraries to provide the user visible
>functionality that was not part of the kernel itself. All the normal file
>operations went through the global library, which either directed them through
>the inherited default I/O Switch operations or to operations provided in an
>installed type manager library.

Interesting...how was this made secure? The OS must have implemented shared
libs in such a way that library code was privileged but user code wasn't...
I don't even want to THINK about statically linked binaries! :-) Reminds
me of Hurd, though.

>By the way, Atria is the inheritor of Apollo's DSEE technology. In normal Unix
>systems, the special functionality that the typed file system provided is now
>mimicked by using an NFS server for accessing the data. It is free to perform
>the special interpretation of file names that the type managers in Domain/OS
>performed.

Loopback NFS is just another way to implement userfs, so my comment about
this not being a kernel issue still applies. It IS an interesting idea,
though.

-- 
Aaron Ucko (ucko@vax1.rockhurst.edu; finger for PGP public key) | Geek Code
3.1 [for explanation, finger hayden@mankato.msus.edu]: GCS/M/S/C d- s+: a18
C++(+++)>++++ UL++>+++ P++(+++) L+++(++++)>+++++ E- W+(-) N++(+) o+ K- w---
O M-@ V-(--) PS++(+++) PE- Y+ PGP(+) t(+) !5 X-- R(-) tv-@ b++(+++) DI+ D--
G++(+++) e>+++++(*) h!>+ r-(--)>+++ y? | "That's right," he said. "We're
philosophers.  We think, therefore we am." -- Terry Pratchett, _Small Gods_