next up previous contents
Next: 4.10 User Level File Up: 4.9 File System Types Previous: 4.9.2 In-Core File Systems

   
4.9.3 Persistent File Systems

Persistent file systems require permanent state. To increase performance and fault tolerance, the state might typically be stored on a local disk, but remote file servers could be used just as well.

Figure fig-fs-persistent shows what happens when file system Y interposes on top of file system X. In that respect it is similar to an in-core file system. However, file system Y also uses an auxiliary file system W.


  
Figure: Vnode Structure in a Persistent File System

Figure: Vnode Structure in a Persistent File System


\epsfig{file=figures/fs-persistent.eps}




6in


\epsfig{file=figures/fs-persistent.eps}


An example stateful file system is Cachefs (Appendix sec-appendix-typical-persistent-cachefs), a file system that is used as a cache by another file system. When the file system is re-mounted the cache could be used again, subject to consistency constraints.

I require that operations on the state-storing file system be vnode operations. This has two benefits:

The restriction brings two disadvantages:

1.
If only a little state is required, it could be stored in a much simpler data structure. Requiring state operations to go through all the file system layers may be unnecessarily costly.

2.
The data structures representing the state may be too complex to be trivially stored in a Unix file system tree structure. Unix file systems offer a traditional tree-like organization. That makes storing state in such a data structure obvious, as there is a one-to-one mapping of source file to auxiliary state file. But what if the auxiliary state that needs to stored requires a more complex data structure, such as a B-tree [Elmasri94] or a graph? In that case, there is no simple way to take advantage of Unix's existing file system structures. Rather, the only way such state can be stored is within one or more ``flat'' Unix files, where an application level process will have to maintain the complex data structures within.

I think, however, that the benefits to my restriction outweigh the disadvantages. I intend to devise a state-storing file system using FiST, called Statefs. This file system -- described in detail in Appendix sec-appendix-typical-in-core-statefs -- will do nothing more than record state for another file system. Statefs will operate inside the kernel, hopefully making its performance a non-issue.

For example, consider the Versionfs file system described in Appendix sec-appendix-typical-persistent-versionfs. Unix file systems do not have versioning capabilities. If one wanted to add version information per file, without modifying the implementation or content of an existing file system, one would have to store the version information in an auxiliary location, and somehow correlate data in the unmodified file system with the auxiliary location. With FiST, one could create a file system that interposes onto two others: the unmodified data file system, and the auxiliary location. The latter can be any type of file system. FiST provides the facilities to make the necessary correlations between the ``source'' file system and the ``auxiliary'' one that is used for storing the extra versioning information. This auxiliary file system is Statefs.

Note that Statefs is an in-core file system. Although it requires storage for itself, the storage need never be interposed upon, and therefore is not considered ``state'' which would make Statefs a persistent file system.


next up previous contents
Next: 4.10 User Level File Up: 4.9 File System Types Previous: 4.9.2 In-Core File Systems
Erez Zadok
1999-12-07