next up previous contents
Next: 2.4 FiST Up: 2.3 Barriers to File Previous: 2.3.2 Commercial Concerns

   
2.3.3 High Development Costs

I have had seven years of personal experience in writing, porting, maintaining, and modifying file systems -- including NFS, Amd, Hlfsd, and LFS -- and ranging across several operating systems. From this experience, I know that while there is a ``nearly standard'' vnode interface, writing or porting a file system to that interface is a substantial task. In addition, file system code is usually tightly coupled internally; many operations depend on others within the same file system. The work cannot be easily parallelized to a large group, and one often finds that a single file system is written by one person. For example, most of the file systems written for Linux have been initially written by individuals. It is often the same small set of developers that develop all the different file systems for an operating system. This is further corroborated from inspection of sources for many public and commercial file systems; I have frequently noted the coding style to be different from one file system to another, while RCS tags and ``Change Log'' entries within the same file system repeatedly made by the same person.

I concluded that, of all possible reasons for the limited diversity of file systems, the most compelling one is the complexity and time involved in overhauling an operating system and all its file systems to a new, albeit better, vnode interface.

Therefore I decided to try to provide vnode interposition and composition capabilities, in a portable way, without requiring kernel sources, and more importantly, without changing existing vnode interfaces. The next section explains my approach, FiST, as the next logical step in the evolution of extensible file systems.


next up previous contents
Next: 2.4 FiST Up: 2.3 Barriers to File Previous: 2.3.2 Commercial Concerns
Erez Zadok
1999-12-07