The Strange and Wonderful Relationship Between File Systems and Operating Systems

Operating systems and file systems are often confused as the same technology because operating systems have traditionally promoted the features of a matching (or "native") file system as highlights of the operating system. In fact, file systems and operating systems are almost always different entities in order to facilitate the development and maintenance of both. The development of a system and the subsequent patches and upgrades that are bound to occur are much easier to work with if the operating and file systems can be treated as independent software entities.

NOTE

Microsoft's decision to delay the introduction of the WINFS file system in their Longhorn operating system emphasizes the fact that file systems and operating systems are, indeed, different things.

File systems determine many of the usage characteristics of a system. End users typically develop their attitudes, likes, and dislikes about a system based on how easy, difficult, or powerful the file system is. One could argue that the file system is almost as important to the usability of a system as the system's user interface. Clearly, the representation of the file system is one of the most important aspects of any operating system.

The Separation of Time and Space in Systems

Operating systems are complex software products that provide access to all systems resources. However, when considering storage processes, it can help to narrow the scope of the operating system to its storage role. Within the context of storage operations, the main difference between operating systems and file systems is that operating systems manage CPU resources by scheduling the relative time a process runs, and file systems manage storage resources by placing data within a storage address space. This difference is illustrated in Figure 14-1.

Figure 14-1. Operating Systems Manage CPU Time Resources, and File Systems Manage Storage Address Space Resources

It is worth pointing out that operating systems control access to storage host bus adapters (HBAs) through their device driver interfaces. In other words, the operating system, not the file system, is the system software that engages storing-level processes.

File systems depend on operating systems to supply the fundamental parameters for the storage address spaces they manage. For instance, the operating system supplies information about the number of blocks that are in a certain storage address space when the file system is initially created. Beyond that, the job of managing how storage space is used belongs to the file system.

NOTE

Most descriptions of file system designs assume a disk drive is being used to provide the storage address space. Of course, in a network storage environment, the actual disk drives are abstracted from the file system by layers of RAID controllers, virtualization systems, or volume management software. So don't be fooled if you read something else about how a file system works with disk drives: substitute "storage address space" for "disk drive," and you'll be better off.

File Systems as High-Priority Applications

It can be helpful to think of a file system as another application running in a system with special requirements and access capabilities. File systems have their work scheduled by the operating system like any other application, although the file system is often called on to do work that interrupts some other application process that may be running. For that reason, file systems have to run very efficiently. A simple end-user operation such as saving or renaming a file might involve many small and intricate steps by the file system to make sure the file is created or updated correctly and that it can be accessed without problems in the future.

File systems run in both kernel space and user space, depending on the function they are performing and the design of the particular file system. For instance, an operation that searches for a file named "my dog has fleas" is likely to run in user space, while an operation that reads data from the same file on behalf on an application is likely to run in kernel space.

NOTE

The sequence of steps involved and the number of operating system-file interactions that occur are somewhat of a mystery, even to people who have intimate knowledge of both products. There are no clear, crisp exchanges like one expects from studying OSI reference models in networking. It's more like watching two people standing in a phone booth playing a game of tag.

Compared with most other applications, file systems have to be extremely robust and avoid failures or errors that could cause a system failure. You simply cannot afford to have unrecoverable application errors in file systems, because they would result in lost or inconsistent data.

Public and Private Interfaces

The development process for a commercial operating system often corresponds with a parallel effort to develop a native file system that will be distributed with the operating system. At this time there may be a substantial amount of interaction between the two development teams. However, after the operating system is released, there is an established method of interaction that could be used by other file systems.

Whether that interaction method is published as an open interface or unpublished as a closed interface depends on the technology and marketing strategies of the operating system developer. Of course, it is possible for an operating system vendor to use unpublished interfaces for its native file system while still allowing nonnative, third-party file systems to work through published interfaces.