At Tue, 23 Jun 2020 11:09:57 +0200, Paul Ruizendaal 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms