Wrapfs and the examples here prove that useful, non-trivial vnode stackable file systems can be implemented on modern operating systems without having to change the rest of the system. We achieve better performance by running the file systems in the kernel instead of at user-level. File systems built from Wrapfs are more portable than other kernel-based file systems because they interact directly with a (mostly) standard vnode interface.
Most complications discovered while developing Wrapfs stemmed from two problems. First, the vnode interface is not self-contained; the VM system, for example, offers memory mapped files, but to properly handle them we had to manipulate lower level file systems and MMU/TLB hardware. Second, several vnode calls (such as readdir) are poorly designed.
Estimating the complexity of software is a difficult task. Kernel development in particular is slow and costly because of the hostile development environment. Furthermore, personal experience of the developers figure heavily in the cost of development and testing of file systems. Nevertheless, it is our assertion that once Wrapfs is ported to a new operating system, other non-trivial file systems built from it can be prototyped in a matter of hours or days. We estimate that Wrapfs can be ported to any operating system in less than one month, as long as it has a vnode interface that provides a private opaque field for each of the major data structures of the file system. In comparison, traditional file system development often takes a few months to several years.
Wrapfs saves developers from dealing with kernel internals, and allows them to concentrate on the specifics of the file system they are developing. We hope that with Wrapfs, other developers could prototype new file systems to try new ideas, develop fully working ones, and port them to various operating systems--bringing the complexity of file system development down to the level of common user-level software.
We believe that a truly stackable file system interface could significantly improve portability, especially if adopted by the main Unix vendors. We think that Spring[10] has a very suitable interface. If that interface becomes popular, it might result in the development of many practical file systems.
We would like to add to Wrapfs an API for manipulating file attributes. We did not deem it important for the initial implementation because we were able to manipulate the attributes needed in one place anyway.
Wrapfs cannot properly handle file systems that change the size of the file data, such as with compression, because these change file offsets. Such a file system may have to arbitrarily shift data bytes making it difficult to manipulate the file in fixed data chunks. We considered several designs, but did not implement any, because they would have complicated Wrapfs's code too much, and would mostly benefit compression.