Ideas for changes to Unix filesystem
Guy Harris
guy at auspex.auspex.com
Tue Feb 12 09:00:26 AEST 1991
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.
More information about the Comp.unix.internals
mailing list