Fork us on GitHub Follow us on Facebook Follow us on Twitter

Version 14 (modified by Jakub Jermář, 10 years ago) (diff)

Implementation and design of the file system layer

Unlike in monolithic designs, the file system functionality is spread across several layers in HelenOS:

Standard library support

The standard library translates more or less POSIX file system requests made by the user application to the VFS server frontend protocol and passes them to VFS. The library emulates some calls such as opendir(), readdir(), rewinddir() and closedir() using other calls. In this case these will be open(), read(), lseek() and close().

The VFS server accepts only absolute file paths and so the standard library takes care of providing the getcwd() and chdir() interfaces. It also translates all relative paths to absolute. Passing absolute paths may not be always optimal, but it simplifies the design of the VFS server and the libfs algorithms. In addition, thanks to this feature, the dot-dot file path components can be processed lexically, which leads to further simplifications.

The standard library forwards all other requests, which it is unable to handle itslef, to the VFS server and does not contribute to the file system functionality by any other means. Each file system request forwarded to VFS is composed of one or more IPC phone calls.

VFS server

The VFS server is the focal point and also the most complex element of the file system support in the HelenOS operating system. It exists as a standalone user task. We talk about the VFS frontend and VFS backend.

VFS frontend

The frontend is responsible for accepting requests from the client tasks. For each client, VFS spawns a dedicated connection fibril which handles to connection. Arguments of the incoming requests are either absolute file paths, file handles of already opened files, and in some special cases also VFS triplets (see below). Regardless of their type, the arguments typically reference some file and, as we will see later, the frontend always converts this reference to an internal representation called VFS node.

Paths as Arguments

If the argument is a file path, VFS uses the vfs_lookup_internal() function to translate the path into the so called lookup result represented by the vfs_lookup_res_t type. The lookup result predominantly contains a VFS triplet, which is an ordered triplet containing a global handle of the file system instance, a global device handle and a file index. Thus a VFS triplet uniquely identifies a file on some file system instance. An example VFS triplet could look like this:

        (2, 1, 10)

In the above example, the VFS triplet describes a file on a file system which was assigned number 2 by the VFS service, located on a device, which was assigned number 1 by the DEVMAP service, and which has a file-system specific index number 10. The last number is also known as i-node number in other operating systems.

VFS keeps information about each referenced file in an abstraction called VFS node, for which there is the vfs_node_t type. Thus, a VFS node represents some file which is referenced by VFS. VFS nodes are the first class entities in the VFS server, because for most operations it needs to have the VFS node.

The VFS server calls the vfs_node_get() function in order to get a VFS node for the corresponding lookup result. This function creates a new VFS node or adds a reference to an existing one. VFS nodes are organized in a hash table with the VFS triplet as a search key.

The following example illustrates how the VFS server obtains the VFS node in the implementation of the unlink operation:

        int rc;
        int lflag = ...;
        char *path = ...;    /* file path */
        ...
        vfs_lookup_res_t lr;
        rc = vfs_lookup_internal(path, lflag | L_UNLINK, &lr, NULL);
        if (rc != EOK) {
             /* handle error */
             ...
        }
   
        vfs_node_t *node = vfs_node_get(&lr);
        /* now we have a reference to the node and work with it */
        ...
        vfs_node_put(node);

The example is simplified and does not show all the details (e.g. it omits all synchronization), but it shows the main idea. Note the trailing vfs_node_put() function which drops a reference to a VFS node. If the last reference is dropped from a node, vfs_node_put() removes it from the hash table and cleans it up.

Handles as Arguments

The VFS server understands file handles and can accept them as arguments for VFS requests made by the client. Each client is using its private set of file handles to refer to its open files. VFS maintains each client's open files in a table of open files, which is local to the servicing connection fibril. The table is composed of 'vfs_file_t pointers and the file handles index it. The associated connection fibril does not need to synchronize accesses to the table of open files because it is its exclusive owner.

The vfs_file_t structures track things like how many file handles reference it, the current position in the open file and the corresponding VFS node. The transition from a file handle to a VFS node is therefore straightforward.