Messages in this thread |  | | Date | Sat, 29 Jun 1996 13:47:21 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Re: Network performance |
| |
Date: Sat, 29 Jun 1996 15:17:01 -0600 (CST) From: Aaron Ucko <UCKO@vax1.rockhurst.edu>
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 overhead.
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 performed.
Leonard
|  |