[lkml]   [1996]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Network performance
  Date: 	Sat, 29 Jun 1996 15:17:01 -0600 (CST)
From: Aaron Ucko <>

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.

[discussion of type managers omitted]

Interesting concept, but it looks as if it could have a fair amount of

Not really.

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.

Here's an example of something that was very easy to implement: I created a
type manager that stored all files as encrypted objects. Most of the normal
file operations were merely inherited. Read and write made use of the normal
file operations, and then decrypted or encrypted the data on the way to the
user process. Since the backup utility backed up "objects" rather than merely
"files", it would happily backup the encrypted data without needing to know
anything special about it.

This implementation also had the advantage over the loopback or CFS methods in
that the granularity is at the file level, not the file system or directory.

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


 \ /
  Last update: 2005-03-22 13:37    [W:0.019 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site