next up previous
Next: 2. Design Up: Extending File Systems Using Previous: Extending File Systems Using


1. Introduction

Adding functionality to existing file systems in an easy manner has always been desirable. Several ideas have been proposed and some prototypes implemented[6,14,18]. None of the proposals for a new extensible file system interface has made it to commonly used Unix operating systems. The main reasons are the significant changes that overhauling the file system interface would require, and the impact it would have on performance.

Kernel-resident native file systems are those that interact directly with lower level media such as disks[9] and networks[11,16]. Writing such file systems is difficult because it requires deep understanding of specific operating system internals, especially the interaction with device drivers and the virtual memory system. Once such a file system is written, porting it to another operating system is just as difficult as the initial implementation, because specifics of different operating systems vary significantly.

Others have resorted to writing file systems at the user level. These file systems work similarly to the Amd automounter[13] and are based on an NFS server. While it is easier to develop user-level file servers, they suffer from poor performance due to the high number of context switches they incur. This limits the usefulness of such file systems. Later works, such as Autofs[3], attempt to solve this problem by moving critical parts of the automounter into the kernel.

We propose a compromise solution to these problems: writing kernel resident file systems that use existing native file systems, exposing to the user a vnode interface that is similar even across different operating systems. Doing so results in performance similar to that of kernel-resident systems, with development effort on par with user level file systems. Specifically, we provide a template Wrapper File System called Wrapfs. Wrapfs can wrap (mount) itself on top of one or more existing directories, and act as an intermediary between the user accessing the mount point and the lower level file system it is mounted on. Wrapfs can transparently change the behavior of the file system, while keeping the underlying media unaware of the upper-level changes. The Wrapfs template takes care of many file system internals and operating system bookkeeping, and it provides the developer with simple hooks to manipulate the data and attributes of the lower file system's objects.

1.1 The Stackable Vnode Interface

Wrapfs is implemented as a stackable vnode interface. A Virtual Node or vnode is a data structure used within Unix-based operating systems to represent an open file, directory, or other entities that can appear in the file system name-space. A vnode does not expose what type of physical file system it implements. The vnode interface allows higher level operating system modules to perform operations on vnodes uniformly. The virtual file system (VFS) contains the common file system code of the vnode interface.

One improvement to the vnode concept is vnode stacking[6,14,18], a technique for modularizing file system functions by allowing one vnode interface implementation to call another. Before stacking existed, there was only one vnode interface implementation; higher level operating system code called the vnode interface which in turn called code for a specific file system. With vnode stacking, several implementations may exist and may call each other in sequence: the code for a certain operation at stack level N typically calls the corresponding operation at level N-1, and so on.

Figure 1: A Vnode Stackable File System
\epsfig{file=figures/wrapfs3.eps, width=3in, height=1.7in}\vspace{-0.5em}

Figure 1 shows the structure for a simple, single-level stackable wrapper file system. System calls are translated into VFS calls, which in turn invoke their Wrapfs equivalents. Wrapfs again invokes generic VFS operations, and the latter call their respective lower level file system operations. Wrapfs calls the lower level file system without knowing who or what type it is.

The rest of this paper is organized as follows. Section 2 discusses the design of Wrapfs. Section 3 details Wrapfs's implementation, and issues relating to its portability to various platforms. Section 4 describes four example file systems written using Wrapfs; Section 5 evaluates their performance and portability. We survey related works in Section 6 and conclude in Section 7.

next up previous
Next: 2. Design Up: Extending File Systems Using Previous: Extending File Systems Using
Erez Zadok