The Storage Kit: File System Architecture

All file systems that the BeOS recognizes are organized hierarchically. Most file systems use hierarchical organization naturally; any other type of system must be adapted at the "file system handler" level to simulate a hierarchy. The result is that all file systems can be treated similarly in terms of their organizational architecture.

The Short Story

If you're in a hurry and don't care to get into the details, here's all you really have to know

File System Layout

• The root of the entire file system hierarchy is "/". This is an actual directory.

• Directly beneath "/" is a layer of directories and symbolic links. The directories can only be used as mount points for other file systems (disks, CD-ROMs, etc). The symbolic links can point to anything you want them to point to. This layer can not contain plain files.

• When the OS is launched, some number of file systems are automatically mounted. Each is mounted at mount point (just under "/") that takes the name /disk_name (for persistent file systems).

• An exception to this is the boot disk: It's mounted at /boot. The OS creates a symbolic link called /boot_disk_name that points to /boot.

• The BeOS creates certain virtual file systems. These are file system that have no persistent storage--the "files" they contain exist only in memory. You can visit these file systems through the shell, but not through the Tracker: the Tracker does not display virtual file systems. Currently, the BeOS creates two virtual file systems: /dev and /pipe.

• Symbolic links are supported; hard links are not (currently).

Navigating the File System

• If your application needs to get to a well-defined watering hole (such as the directory where a user's preference settings are stored, or where apps are kept), use the symbolic pathname constants that are defined by the find_directory() function.

• Avoid using hard-coded absolute pathnames in your app. Relative pathnames are okay, especially if they're reckoned off of one of the find_directory() constants.

Hierarchical Organization

The tenets of a Be-recognized hierarchical file system are these:

• Data is organized as a tree of directories and files.

• Directories contain files.

• Each file is a member of only one directory (at a time). The directory is said to be the file's "parent." Once hard links are supported (as explained below) the one-parent rule will no longer hold.

• Similarly, each directory has a single parent (directory).

• The hierarchy "fans out" from the file system's root directory. The root directory is the common ancestor for all files and directories in the hierarchy.

• Every file and directory has a "leaf" name; leaf names must be unique within the containing directory.

• The only illegal character in a leaf name (in the Be File System) is "/". Also, every directory automatically contains entries named "." and "..".

In the BeOS, more than one file system can be mounted at a time. Each distinct file system is mounted within the root file system (described in the next section). Because of this, all (non-root) file systems maintain distinct boundaries. However, these otherwise-tidy boundaries are smudged a bit by...

Symbolic Links. The BeOS recognizes symbolic links. A symbolic link (or "symlink") is a file that "points to" some other entry (another file, directory, or symbolic link). This other entry can live anywhere--in some other directory, or even in another file system. Because of symbolic links, the graph of the hierarchy isn't acyclic: As you follow a path through the hierarchy, it's possible to get into a loop. (If you leave symbolic links out of the picture, the graph is acyclic.)

Currently, the BeOS does not recognize hard links (although it will in the future). A hard link associates an entry in the hierarchy with a specific chunk of data (a node). The attraction of hard links is that more than one entry can be associated with the same node.

File System Layout and the Root File System

Before looking at the file system layout, let's get one thing clear. The term "file system" is a heavily loaded monicker:

• At the lowest level, it means a "file system format." Currently, the BeOS recognizes BFS, HFS (Macintosh), and ISO9660 (CD-ROM) file system formats.

• "File system" can also mean the agent that knows how to turn bytes on a disk (or even in memory, as described in "Virtual File Systems") into the sort of hierarchy that the OS wants to see. When you pop in a floppy, for example, a file system handler must wrangle the disk format to convert its contents into a recognized hierarchy. When we say that the BeOS recognizes HFS, we're really saying that we provide an HFS file system handler. See "File System Handlers" for more.

• Yet another meaning of "file system" is that part of the OS that manages and lays out all the file systems that are mounted. It's the uber-system for all hierarchies.

In the BeOS, this uber-system is part of the kernel. The first thing it does is mount the root file system. All other file systems are mounted within the root file system.

The structure of the root file system is a simple, two-level hierarchy:

• The root directory of the root file system is "/". This is the only directory in the entire hierarchy that doesn't have a parent.

• The nodes in the root file system are directories and symlinks only. In other words, the root file system contains no real files.

The directories in the root file system have a prescribed purpose:

• The directories are mount points for other file systems. A mount point becomes the root directory for the file system that's mounted there. (More accurately, the name of the mount point becomes the name of the root directory; the mount point directory itself is "obscured" when a file system is mounted on it.)

• You can create your own directories in the root file system, but they can only be used as mount points--you can't use them to store files (for example).

The symlinks in the root file system are less restricted. The OS creates some number of symlinks automatically (as described below), but other than that, you're free to put whatever symlinks you want in the root file system. However...

"Root-level" symlinks are simply a convenience for developers--the user won't be able to see them (the Tracker doesn't display the root file system).

Default Root Nodes

When BeOS is launched, some number of directories and symlinks are automatically created in the root file system. The directories are:

• For each "persistent" file system that the OS finds (hard disks, CD-ROM, floppy, etc.), a mount point directory is created and the file system is mounted. The mount point for the file system that was used to boot the OS is /boot; the other mount point names are taken from the storage devices themselves (if you name your floppy "fido", the floppy will be mounted at /fido).

• The OS also creates two virtual file systems, mounted at /dev and /pipe. We'll look at virtual file systems later. Briefly, a virtual file system is one that only exists in memory--it has no persistent storage. (The root file system itself is a virtual file system.)

And the symlinks:

• A link is made from /boot_disk_name to /boot.

• Links are made from /bin, /system,and /etc to similarly named subdirectories of /boot/beos.

• Links are made from /var to /boot/var and from /tmp to /boot/var/tmp.

If you cd to / in a shell and list the files, you'll see something like this (where "MyDisk" is the name of the boot disk, and "fido" is a floppy):

   l---------   1  users     0 Jun 19 22:11 bin -> /boot/beos/bin
   drwx------   1  users  2048 Jun 19 21:58 boot
   drwxr-x---   1  users     0 Jun 19 22:11 dev
   l---------   1  users     0 Jun 19 22:11 etc -> /boot/beos/etc
   drwxr-xr-x   1  users  2048 Jun 19 22:12 fido
   l---------   1  users     0 Jun 19 22:11 MyDisk -> /boot
   drwxrwxrwx   1  users     0 Jun 19 22:11 pipe
   l---------   1  users     0 Jun 19 22:11 system -> /boot/beos/system
   l---------   1  users     0 Jun 19 22:11 tmp -> /boot/var/tmp
   l---------   1  users     0 Jun 19 22:11 var -> /boot/var

If you invoke df, you'll see the list of mounted file systems:

   Mount            Type     Total    Free     Flags Device                        
   ---------------- -------- -------- -------- ----- ----------------------------  
   /                rootfs          0        0     0                               
   /dev             devfs           0        0     0                               
   /pipe            pipefs          0        0     0                               
   /boot            bfs        532950   395715 70004 /dev/disk/scsi/050/0_2        
   /fido            bfs          1440      904 70004 /dev/disk/floppy/raw          

All file systems, both persistent and virtual, are displayed. The virtual file systems are the ones that have 0 size.

Virtual File Systems

A virtual file system has no backing storage. The hierarchy that it represents is maintained in memory; when you shut down the OS, all virtual file systems disappear.

Currently, the BeOS provides three virtual file system handlers:

• rootfs handles the root file system (described above). The root file systemis mounted at "/". It's always the first file system to be mounted, and provides mount points for all other file systems.

• devfs is the handler for the device file system, mounted at /dev. This system contains entry points for access to hardware devices, including hard disks, CD-ROMs, and so on.

• pipefs is the handler for the pipe file system, mounted at /pipe. A "pipe" is a location through which the POSIX pipe mechanism reads and writes data.

From the developer's perspective, a virtual file system isn't much different from a persistent file system: You can create a BVolume object to represent it, you can walk through it's hierarchy , and look at its contents, and so on.

But virtual file systems are hidden from the Tracker user:

The Tracker does not display virtual file systems, nor does it let the user form a virtual fs query.

File System Handlers

When the kernel attempts to mount a file system, if must first find a file system handler that understands the file system's format. In other words, the handler is an intermediary between the kernel and the bytes on a disk (for example).

All file system handlers are add-ons. The kernel loads the handler add-on that it needs, and talks to it through a set of well-defined functions. The advantage of this approach is that the kernel doesn't need to know about specific file systems, it only needs to know how to talk to the handlers.

Unfortunately, the file system handler API isn't public yet...

Currently, you can't create your own file system handler.

The handler API will be released sometime in the future.

The Be Book, in lovely HTML, for the BeOS Preview Release.

Copyright © 1997 Be, Inc. All rights reserved.

Be is a registered trademark; BeOS, BeBox, BeWare, GeekPort, the Be logo, and the BeOS logo are trademarks of Be, Inc.

Last modified July 17, 1997.