Re: [TUHS] VFS prior to 1984

["Greg A. Woods" <woods@robohack.ca>]

[-- Attachment #1: Type: text/plain, Size: 5575 bytes --]

At Tue, 23 Jun 2020 11:09:57 +0200, Paul Ruizendaal <pnr@planet.nl> wrote:
Subject: [TUHS] VFS prior to 1984
> 
> When googling for File System Switch or Virtual File System most
> sources mention Sun NFS and SysVr3 as the earliest
> implementations. Some sources mention 8th Edition.
> 
> I did a (short) search on FSS/VFS in earlier, non-Unix OS’s (Tenex,
> Multics, CASS, etc.), but none of those seem to have had a comparable
> concept.
> 
> Does anybody recall prior art (prior to 1984) in this area?

Well, with regard to Multics, it had what were called "Device Interface
Modules" (DIMs) for building device drivers to either hardware or
pseudo-devices (an example of a pseudo-DIM is the File System Interface
Module (FSIM) which associates a segment (file) in the filesystem (by
path name) with a stream, i.e. it implements I/O redirection).

DIMs had a well defined API, and as Organick said in his 1972 book:
"The DIM converts a device independent request into a device dependent
one." ... "The file-system interface DIM is used to make a segment look
like an I/O device."

A DIM also had a name, an identifier, and that's how you attached a
"stream" to it:

	call attach (stream_name, DIM_name, device_name);

All of those parameters are strings.

As an aside I haven't found any evidence that DIM identifiers were ever
listed in the filesystem, e.g. as Unix would have in "/dev", but that
would be an obvious thing to do these days.  Then they were just listed
in the programmer's manual, and presumably user-written ones were added
to the online documentation.  Today such an idea would be "obvious".

As far as I can remember Multics didn't really have the concept of a
"mount point".  All storage was single-level, i.e. segments (equivalent
in some respects to inodes, but they are also actually the value of the
segment register in the virtual memory hardware), and so files were
either physically in memory or paged out on physical disk devices or
similar, or even out on tape.  Where they actually resided was entirely
and permanently hidden from the user.  What was called the "filesystem"
was a form of database representing a hierarchical namespace which
pointed at all the known segments (files) regardless of where they were
actually stored.

In terms of virtual filesystems for Multics, I think it would be (have
been) relatively easy enough (i.e. with the addition of some APIs to the
filesystem itself) to implement a way of "mounting" a pseudo-DIM into
the filesystem namespace and thus being able to implement anything from
the likes of /kern and /proc to remote filesystems, network directories,
etc.  I.e. create an inverse twin of the filesystem DIM that takes
filesystem requests and turns them into back-end pseudo-DIM requests.
Effectively this would be implementing a VFS for Multics.  Indeed today,
and perhaps any time after Apollo Domain was designed, it would be
plainly obvious, and probably desirable, to do such a thing, at least
for some kinds of concepts, such as /proc.

Note though that I suspect the original Multics designers would have
preferred it if remote filesystems, in particular, were also effectively
invisible to the user, though I do not know how they might have
approached the issue of remote segments not always being available,
including indeed parts of the filesystem itself, i.e. directories and
metadata.  Perhaps in a similar way to how files migrated to backup
storage were handled -- if you referenced a file that had been migrated
offline then your process trapped to a retrieval process that involved
prompting a human tape operator to load the appropriate backup tape(s).

In fact Organick says the following about this idea of an inverse
relationship between the filesystem and I/O subsystem in his 1972 book
(p351,352):

    "We have just seen how the I/O system may behave as a customer of
    the file system, which supplies needed services.  One might wonder
    if the reverse of those roles is ever true.  That is, does the file
    system through its Page Control Module, when seeking to transfer a
    page of information to/from core [[memory]] and disk or tape
    storage, ever find itself to be a customer of the I/O system?
    Emphasis on objectives of modularity might cause one to guess the
    affirmative.  In actual fact however, considerations of efficiency
    have dictated that paging I/O in Multics be treated with
    special-purpose I/O software that greatly streamlines the
    processor's task in initiating and controlling such I/O."

So, at least early on, he appears to have denied the idea of the
filesystem routing requests through a DIM or pseudo-DIM, though he did
so on the basis that this would be done at the pager level and that
doing so could be too inefficient to consider.  However he doesn't seem
to have considered, or at least does not mention in the 1972 book, the
idea of a pseudo-DIM extending the filesystem namespace by implementing
a mount point, which as I say would today be considered a quite obvious,
desirable, and feasible task.

In any case the idea of pseudo device drivers interacting with the
filesystem, albeit the other way around, was firmly in place by 1965
(the file-system interface pseudo-DIM was described in the 1965 Multics
I/O system paper).

-- 
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]