Ideas for changes to Unix filesystem

[Guy Harris]

In article <1991Feb7.064348.1873 at sgitokyo.nsg.sgi.com> kandall at sgitokyo.nsg.sgi.com (Michael Kandall) writes:
>In article <G2%&-2#@uzi-9mm.fulcrum.bt.co.uk> igb at fulcrum.bt.co.uk (Ian G Batten) writes:
>>In article <BZS.91Feb4003139 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>>> Think of fixed length record files and inserting into them, it would
>>> be nice to be able to just copy/munge the block numbers rather than
>>> the data.
>>
>>What's needed is a version of streams for filesystems.  With Multics,
>>the One True Operating System, you could attach modules (== push
>>modules) such as vfile_ to provide additional functionality over and
>>above that which you got from initiate_segment_ and its friends.  What
>>would be nice with Unix would be ISAM, record mode, whatever modules you
>>could push on top of the mmap interface.  Once you can map files into
>>your address space most things can be done on top of that.
>>
>>ian
>
>I believe SVR4 has this.  In SVR4's enhanced STREAMS, I believe you can
>push STREAMS onto arbitrary file descriptors.

You believe incorrectly.  What S5R4 *does* have is the ability to attach
a STREAMS-device file descriptor to a "node in the file system name
space", using "fattach()".  This does *NOT* magically turn a regular
file into a STREAMS device; it turns it into a name for a STREAMS
device.  I.e., anybody who opens the file after you've "fattach()"ed
something to it will *NOT* get a file descriptor that reads from or
writes to the underlying file; the underlying file merely provides a
*name* for the stream.

What Ian was describing sounds more like the stuff Apollo did - with the
name "Extensible Streams", but where "Streams" has nothing to do with
"streams" in the Research UNIX sense or "STREAMS" in the S5 sense.  The
low-level means of accessing a file is by mapping into a process's
address space; atop that is built a mechanism for more "conventional"
file access, with each file having an "object type UID".  The "object
type UID" indicates what code acts as a "type manager" for the file;
that "type manager" code implements operations such as "open", "read",
"write", etc..  Dunno if they were "stackable" like (streams|STREAMS)
modules.  (Then again, I don't remember whether modules were stackable
in any of Multics's I/O subsystems, either "ios_" or "iox_".)
I think the type managers all lived in user-mode code.

That doesn't necessarily give you the stuff Barry was referring to; the
"containers" provided by the (probably kernel-level) file system are
arrays of pages, similar to UNIX files.  Unless there was an interface
to that file system that let you insert pages into the middle of a
container, you wouldn't be able to do an insert like that.