Filesystem Mount Tables

A process of mounting will be needed to connect mountpoints to filesystems. Traditionally, a mount table is employed to indicate where filesystem entries are mapped to other filesystems. Filesystems might consult a mount table made available to them to determine such relationships.

mountsapplicationvirtual filesystemobjecttableprincipal filesystem/mounted filesystem/...mountpoint//.../mountpoint...

Capabilities are transferred from whichever filesystem provides an object to the application requesting it.

Mount Tables

Although many systems employ global fstab, mnttab and mounts files, since a filesystem only need care about correspondences pertaining to itself, it may have its own mount table which it would consult when being asked to provide access to particular objects. A virtual filesystem would perhaps rely entirely on a mount table, delegating the navigation of the filesystem hierarchy to other filesystems.

A mount table acts as a list of mappings from locations to objects providing filesystem information at those locations. Instantiating the textual form of a mount table, such as fstab, would be a matter of performing a mount operation for each entry in the table.

Mount Operations

Applications (or application environments) would request the mounting or binding of other filesystem hierarchies within a particular filesystem. This is perhaps most similar to the bind operation from Inferno.

It may make sense for applications to present filesystem capabilities to other filesystems in order to bind those capabilities within those other filesystems. This is particularly pertinent when filesystem objects may be operating in the capacity of a particular user.

One can envisage a user wanting to mount a file as a filesystem, such as a disk image made available as a file. Accessing the file is merely a matter of interpreting its data in a particular way, and a user could invoke a program that acts as a filesystem in order to provide access to the contents. This program could then be presented to the virtual filesystem to bind the new filesystem at a certain mountpoint.


Although arbitrary mountpoints may be supported, it might make sense to require them to correspond to existing filesystem objects. Thus, permission information could be transferred from the mountpoint to the mounted filesystem root, dictating whether the mounted filesystem might permit modification or not.

Selecting Filesystems

When presented with a path, the appropriate filesystem should be selected to provide the object denoted by the path. The process of identifying the appropriate filesystem is as follows:

# Employ the root filesystem as the default filesystem.

selected = "/"

for mountpoint in mountpoints:

    # Determine whether the mountpoint is a prefix of the path, testing
    # whether it is longer than the currently-recorded longest matching
    # mountpoint.

    if is_prefix(mountpoint, path) and len(mountpoint) > len(selected):
        selected = mountpoint

For large collections of mountpoints, a more efficient method of searching could be employed.