OSNews

Okay, while it is all fine and dandy to have a system that is extremely easy to navigate for the user and which does away with many of the annoying constraints of modern systems, there is a vast swath of code out there written for the usual, hierarchical structure and which is not going to change over night. Very well, since programmers demand a highly structured disk layout, we shall give it to them in the form of a System group. Like the "blessed" folder on the Mac OS and the root directory on Unix, this is where the off-limits system files and usual hierarchical structure reside. If the program gets a directory listing of "/usr/bin", the file system will return all the files present in the group System -> user -> bin. If a program deletes a file, it disappears from all the groups in which it currently resides. Do note that, although the System group looks just like "/" to the programs, the hierarchical structure is only skin deep. The actual layout on disk bears no resemblance to the hierarchical structure present in System.

Beyond just providing a compatibility layer for older programs, the System group can play a greater role in aiding applications in finding the files/information they need. For instance, even if the user doesn't have all their applications in a single group named "Applications", the System group could contain a group called "Applications" which would have a live query associated with it that found all application files on the system. Hence, no more expensive searching to find the location of a certain application and no more popping up a dialog asking the user to locate one. The same goes with other things of interest to programs such as: all removable media, all USB devices, all connected monitors, etc. Unix started the trend of making everything available through the file system, why not finish it?

So far we've divorced files from their locations, from their names, and from their metadata constraints. Why not divorce them from their file type too? Why not add a plugin architecture (technically not part of the file system, but it's related) which could allow applications to install various filters for certain types of files. Why have to save a file once as a PNG and once as a GIF to have access to both types for different applications? BFS and any related software above it will let applications install a PNG -> GIF converter to allow any application which understands GIF to open and PNG document. A program need not look only for the files it can understand, but simply tell the OS which file types it can accept and let the OS decide whether a given file can be converted to the appropriate type.

Beyond even this, BFS will allow users to create "doppelgangers" of various files whereby any modification to the original file will automatically trigger an update to the doppelganger. Imagine having an important group full of billing information for your company. Create a doppelganger of that group which gzip's the group's contents into a backup archive. As changes are made to the original files, the doppelganger is replaced with the compressed, updated files. The link between the original file and its doppelganger can be broken at any time, thus making it easy to create stationary snapshots.

The user interface for all this should probably be much like the spacial Finder of Mac OS 9. However, the multitude of windows spawned should be cut down to one. A zooming interface wherein groups and their contents zoom out to let you inspect them is probably better suited to navigation. The desktop metaphor works very well with the group metaphor in that the desktop is always your temporary dock where you can toss stuff onto and then wipe clean again. Note that tossing files on to the desktop does not remove them from their previous groups. You need to issue a "remove" command to make that happen. Groups should probably be displayed as a clump of the files it contains. This allows the user to quickly glance and see which groups are fuller than others.

Files, without a location, without a specific group to belong to, without even a name, should be identified at all times by a unique number, probably 64 or 128 bits in length. This number should be unique to the volume that they are on and should be intelligently used by the system to find a given file and to index information about a file. For instance, there might be various B+trees scattered about the disk, all of them containing a portion of inode lookup tables (sort of like the directory structure of today). A file with a number ending in 16 one bits would be found in the B+tree associated with 16 final one bits and so on. The file number should be persistent so that applications can store the number in a file and then find the file again after a restart. Note that the file number does not depend at all upon which group(s) the file resides in.

Metadata is likely to take the form of a small file and can probably be efficiently packed into blocks with other small metadata files. Various techniques like placing the first couple of bytes directly after the file inode should also help. Metadata journaling should be present as well.

Finally, the elimination of a hierarchical structure should free the implementor from having to worry about unbalanced directories, strange create/delete patterns that strain block allocation policies, etc. Further, no centralized directory need exist; all information for a section of the disk could be stored at the head of the section like ext2 and could be easily recovered and indexed at boot time.

As I have said previously, the current hierarchical structure of file systems is unnecessarily constraining. Creating a more free-form storage allows the user or the System group to create hierarchy when necessary and refrain from doing so when unnecessary. The end result is a system more suited to a user's organizational skills and less dependent on the fragility of keeping a location and name for every file on the system. Addition of superior metadata handling is the coupe de grace which creates order out of chaos and fully exploits the human ability to describe rather than identify.

Raskin, Jef The Humane Interface Addison-Wesley, 2000

An excellent introduction and forward-looking view of human-interface design. A must for any serious programmer dealing with GUIs. Check out his website http://humane.sourceforge.net/home/index.html.

Giampaolo, Dominic Practical File System Design Morgan Kaufman Publishers, Inc., 1999

The creator of the Be file system tells you everything you ever wanted to know about creating a file system. Very interesting read. Buy it at Amazon.

Reiser, Hans Name Spaces as Tools http://www.namesys.com/whitepaper.html

The creator of the ReiserFS talks about his vision for the future of file systems. Rambling, at times completely incoherent, but holds a couple of jewels of insight. Be sure to check out the section: "Storage Layers Above the FS: A Sure Sign the Developer Has Failed".

About the Author:
"I am currently a junior at the University of Wisconsin - Madison studying Mathematics. In my spare time I program for fun and profit for a small company doing graphical logging of roadways. I also manage to inflict on the world my limited theatrical talents by performing in plays, musicals, and the like."

1. "Brendan File System, Part I"
2. "Brendan File System, Part II"