I've wanted somewhat different file system semantics, but close to the POSIX model:<p>- Unit files. The unit of consistency is the entire file. Files are opened for writing, written, and closed. Then then become openable by other programs. Overwriting a file replaces the file as a unit; other readers see the old file until the writer closes and the reader reopens. This is the default and the case for most files. On a crash, the file reverts to the previous good file, if any. Can be memory-mapped as read only. File replacement can be done now through non-portable renaming gyrations. It should just work.<p>- Log files. Append-only mode, enforced. Can't seek back and overwrite. On a crash, the file recovers to some recent good write, with a correct end of file position. It does not tail off into junk.<p>- Temp files. Not persistent over restarts. Not backed up. Can be memory-mapped as read/write. On a crash, disappears.<p>- Managed files. These are for databases. Async I/O available. May have additional locking functions. Separate completion returns for "accepted data" (caller can reuse write buffer) and "committed data" (safely stored), so the database knows when the data has been safely stored. Can be memory-mapped as read/write. Intended for use by programs which are very aware of the file system semantics. On a crash, "committed data" should be intact but data not yet committed may be lost.
Article describes Multics’ ability to have a file's directory entry on disk but its contents on tape, so trying to access its contents will cause it to be retrieved from tape, and then asks "Is something like this offered on any POSIX-compatible file system?"<p>What the article is describing is basically just HSM (Hierarchical Storage Management), which is a commercially available technology – e.g. Sun/Oracle SAM-QFS on Solaris, IBM Tivoli Storage Manager on AIX, DFSMShsm on z/OS.<p>Windows NTFS also supports HSM, although the core NTFS itself only provides features necessary to implement HSM (such as FILE_ATTRIBUTE_OFFLINE and reparse points), and you need an add-on to Windows to actually use those features to produce a full HSM solution. (Actually Windows itself used to include such a solution, Remote Storage Service, but Microsoft removed it in Windows Server 2008 onwards; but the underlying functionality is still there in NTFS, and available for third party HSM implementations to exploit.)
Surprised no mention of plan9's FS. It always seemed like the core innovation in plan9.<p>Basically, everything is a file. But to a ridiculous extent, far beyond what you'd normally think of as files. It's been years since I looked into it though, so maybe I'm misremembering.<p>Designing it that way has lots of advantages. For example, you can connect computers together via networks using the equivalent of `cat`. (And yes, we have netcat, but it's not quite the same thing as having the abstraction built into the OS.)
This is incidentally why the Common Lisp file I/O functions are a bit more complicated than you might expect. You can ignore most of it if you assume something vaguely POSIX-like, but if you want to be portable to e.g. both Unix and VMS (as was once desirable), there are functions like <i>make-pathname</i> that build a representation of a file location from up to 6 parameters (host, device, directory, name, type, and version). The 3 examples in the docs are interesting: <a href="http://clhs.lisp.se/Body/f_mk_pn.htm" rel="nofollow">http://clhs.lisp.se/Body/f_mk_pn.htm</a>
This is a good read. I believe that Steve Bourne (of Bourne Shell fame) implemented the file system in UNIX at Bell Labs but I may be mis-remembering that. He was also a big Multics fan.<p>What is unsaid in this article is that nearly all file systems that are in widespread use today, started when "disk space" was a constrained resource. It is a very reasonable thing to ask, "now that stable storage space is much more plentiful, how might we design systems that are better than the current ones?"<p>The ability to scavenge blocks to re-create state is a good example of that.<p>One of the cool things about WAFL (the Write Anywhere File Layout) system that NetApp used (uses?) was that it's very design made snapshots 'trivial' since every write to disk was to un-allocated blocks. What that meant in practice was that the file system on disk was <i>always</i> sane. This was what let you pull the power from the box at any time, and assuming its non-volatile RAM was still available, it could always recover. Something that you could do with Intel Cross Point memory and a bunch of disks.<p>Microsoft research built a number of interesting file systems, some more successful than others, which incorporated many of the ideas from Multics and other OSes.<p>All in all, its a fun place to experiment.
I was expecting another article about the current crop of <i>less than</i> POSIX filesystems, but I was pleasantly surprised to find it was about older systems with features <i>absent</i> in POSIX. Very interesting stuff. Kudos. I wonder if I can find some information about MTS's filesystem, which also had some neat features especially with respect to access control (PKEYs). Might be a worthwhile addition.
I was fortunate enough to be working for Basho and attended the RICON where mrb gave his distributed systems archaeology talk. It really highlighted for me how so many important ideas are captured in historical whitepapers and often forgotten today.<p><a href="https://speakerdeck.com/mrb/distributed-systems-archaeology" rel="nofollow">https://speakerdeck.com/mrb/distributed-systems-archaeology</a><p>Regrettably many RICON talks were lost when Basho went out of business, but someone rescued this one. Thanks Alex Ott!<p><a href="https://youtu.be/om_mAaM5sL8" rel="nofollow">https://youtu.be/om_mAaM5sL8</a>
Acorn's "ADFS", as used in RISC OS, uses "." as the directory separator. Fully qualified paths look like this:<p>fs::drive_id.$.directory.directory.filename<p>Where "$" means "root directory". (On network filesystems, you can also use "&" which means "home directory".)<p>The top level identifier is the filesystem type, usually "adfs", which is a slightly unusual way of doing it.<p>Bringing in files from other systems, which invariably have filename extensions, involves converting the . to a /, so you end up with filenames like "readme/txt". ADFS stores the file type not as a filename extension, but as a three-character hex ID in the filesystem instead. (Text, for example, is FFF.)
Having used both Multics and the Alto, I can add a few points:<p>Multics as implemented used a slightly different syntax, such as > for path separation.<p>Segments were not file descriptors but were intended to be what might today be called blocks. The original idea was that the entire memory would essentially be a single address space, with segments being blocks of memory that might be in core, on disk, or on tape (called very slow storage if I remember correctly but it’s been decades). Security was at the segment level, so you could for example have (in posix parlance) an suid shared library that an ordinary program could, with appropriate authentication and permissions, call into in a controlled manner. Multics’ permission structure was more fine grained than the binary of suid. You can see how the backup system kind of falls out of this automatically. I trust some multician will step up and correct any memory-corruption-based thinkos in the above.<p>Of course reality didn’t quite match the dream and Multics was cancelled before some of that research could be completed. But if you look at the x86 segment registers they could implement something like that. I think this was also in the intel iapx-430 but fortunately even the name of that ancient dead processor is hazy in my mind.<p>As for the alto filesystem and its descendants: the labels don’t have to be next to the blocks they describe. After all Unix filesystems have multiple copies of their basic breadcrumbs at least. There’s certainly plenty of room for these in modern storage systems; every modern drive, whether spinning or ssd, does a small amount of this in block remapping and wear leveling.
FUSE allows you to experiment new (or old) features easily nowadays, too bad it isn't mentionned in the article:<p><a href="https://en.wikipedia.org/wiki/Filesystem_in_Userspace" rel="nofollow">https://en.wikipedia.org/wiki/Filesystem_in_Userspace</a><p>I use borg mount to access my backups for example.
>"The very first hierarchical file system was developed for Multics. It is described in the paper A General-Purpose File System For Secondary Storage (1965) by Robert C. Daley and Peter G. Neumann. There are several things that I find astounding about this paper:<p>There were apparently no hierarchical file systems before Multics. The references do no cite any previous work on this and I haven’t found any."<p>(PDS: As an amateur computer historian, I'd be interested in this myself, if there existed any hierarchical file system before Multics, or if one was conceived in any academic paper before the one cited...)<p>[...]<p>>"Directory entries that point to secondary storage. <i>This is a game changer for file system management.</i> More on this below."<p>(PDS: Which, to this day, is one of the great abstractions, one of the <i>great ideas</i>, in computing!)
For anybody who has the desire and opportunity to interact with something currently in production and truly alien-feeling, I warmly suggest IBM’s AS/400 (now iSeries) OS/400’s filesystem. Library versus folders, logical versus physical files, integrated DB2 database is one of the many, many head-scratchers you’ll encounter until you suddenly “_get it_”.
Portability was important and so more complex capabilities were not sufficiently used to survive and spread. I wonder how the similar struggle ends for advanced cloud features.
Anyone remembers Novel NSS? Even when it got ported to Linux as part of Open Enterprise Server it lacked a lot of POSIX features. The ACLs were the weirdest part since they had to be configured in eDirectory’s LDAP console.
What I really want that isn't there in POSIX is not directly a file system feature but something more general: I really want some sort of "middleware-system" to intercept all sorts of events (like file system access, binary execution, network or device access etc.). There should be multiple intercepting programs that handle one or more events each and can decide to block or pass the event to the next interceptor. They could also log or modify parameters of the event (like redirect a file read or wrap a binary that's about to be executed in another program like script or torsocks).<p>You could even use this system to implement some Unix features as interceptors: Shebangs and even file system permissions could be handled this way. You could also implement containers with this or provide some kind of "switchboard" UI akin to uMatrix for letting the user decide on permissions.
It would be interesting if a "file type" existed to provide these more complex operations, and if those could also be bound to a daemon running with provided parameters.<p>This would allow for a filesystem name linked to a database API / any other daemon or program.<p>I also love the TRAP (related to above) and both directory operations. Quotas can sort of fulfill the space limits thing (but I've never bothered using such a system and haven't been on a system that did). Append Only directories are a far harder beast to slay, but would very nicely fulfill many queue submission systems.
No mention of the immutable content addressable hash file system presented in the Artifacts System[]. One of the benefits of a system like this is that you can have multiple versions of a library coexisting without conflict with your requirements system. Each program can reference a different hash, duplicates are easily made unnecessary because they resolve to the same hash, etc.<p>[]<a href="https://apps.dtic.mil/dtic/tr/fulltext/u2/a276589.pdf" rel="nofollow">https://apps.dtic.mil/dtic/tr/fulltext/u2/a276589.pdf</a>
<i>> Why can your browser run sudo? ...Suppose only your SSH client had the operation required to use your SSH keys.</i><p>Perhaps I’m missing something, but why could a malicious application (say, Chrome in the context of a browser running sudo) not also include the capability to access the file system with impunity?<p>It seems that Hydra simply turns the technical problem of managing filesystem protections into a political one, of auditing the applications we use; which may have been practical in the 80’s, but is now demonstrably a failed method of protecting user data.
Interesting POSIX history. It used to come down to Windows/Mac and POSIX, but for the past 20 or so years we've been seeing new filesystem styles emerge, which blend cloud and on-device storage. Navigating the iOS file save menu is a good example. 3rd party apps like Google Drive and DropBox hook into the OS and show up in the list. I think this is probably the way things are headed, and POSIX and the "Windows/DOS/Classic Mac" style will both fade away.
Fascinating to see other possibilities that were out there. Were the capabilities in Hydra the inspiration for what Fuchsia OS has, or are they a long standing concept?
<i>> When you use a file system through a library instead of going through the operating system there are some extra possibilities. You are no longer required to obey the host operating system’s semantics for filenames. You get to decide if you use / or \ to separate directory components (or something else altogether)</i><p>This is really about time in 2020 that someone (Apple, MS, Linux, FreeBSD, Plan 9 I'm looking at you) implemented this!
This is a great article. For anyone wondering about the current data storage stack on Unix-like systems today, I wrote a simple article that goes over it [1].<p>[1] <a href="https://venam.nixers.net/blog/unix/2017/11/05/unix-filesystem.html" rel="nofollow">https://venam.nixers.net/blog/unix/2017/11/05/unix-filesyste...</a>
Maybe another filesystem worth mentioning would be WinFS.<p>It should have been one of the major features of Windows Longhorn, which later became Vista.<p>Simply put, it was a relational database, with features you typically find in RDBMS like Postgres or Microsoft's own SQL Server, which took advantage of some of the work done on WinFS.