The Desktop File System
Morgan A. Clark, Stephen Rago · USENIX Summer Technical Conference · 1994
This paper describes the structure and performance characteristics of a commercial file system designed for use on desktop, laptop, and notebook computers running the UNIX operating system. Such systems are characterized by their small disk drives dictated by system size and power requirements. In addition, these systems are often used by people who have little or no experience administering Unix systems. The Desktop File System attempts to improve overall system usability by transparently compressing files, increasing file system reliability, and simplifying administrative interfaces. The Desktop File System has been in production use for over a year, and will be included in future versions of the SCO Open Desktop Unix system. Although originally intended for a desktop environment, the file system is also being used on many larger, server-style machines. 1. Overview This paper describes a commercial file system designed for use on desktop, laptop, and notebook computers running the UNIX operating system. We describe design choices made and discuss some of the interesting ramifications of those choices. The most notable characteristic of the file system is its ability to compress and decompress files ‘‘on-the-fly.’’ We provide performance information that proves such a file system is a viable option in the Unix marketplace. When we use the term ‘‘commercial file system,’’ we mean to imply two things. First, the file system is used in real life. It is not a prototype, nor is it a research project. Second, our design choices were limited to the scope of the file system. We were not free to rewrite portions of the base operating system to meet our needs, with one exception (we provided our own routines to access the system buffer cache). 1.1 Goals Our goals in designing the Desktop File System (DTFS) were influenced by our impressions of what the environment was like for small computer systems, such as desktop and laptop computers. The physical size of these systems limits the size of the power supplies and hard disk drives that they can use at a reasonable cost. Systems that are powered by batteries attempt to use small disks to minimize the power drained by the disk, thus increasing the amount of time that the system can be used before requiring that the batteries be recharged. It is common to find disk sizes in the range of 80 to 300 Megabytes in current 80x86-based laptop and notebook systems. Documentation for current versions of UnixWare recommend a minimum of 80 MB of disk space for the personal edition, and 120 MB for the application server. Similarly, Solaris documentation stipulates a minimum of 200 MB of disk space. These recommendations do not include space for additional software packages. We also had the impression that desktop and notebook computers were less likely to be administered properly than larger systems in a general computing facility, because the primary user of the systems will probably be performing the administrative procedures, often without the experience of professional system administrators. These impressions led us to the following goals: • Reduce the amount of disk space needed by conventional file systems. • Increase file system robustness in the presence of abnormal system failures. • Minimize any performance degradation that might arise because of data compression. • Simplify administrative interfaces when possible. The most obvious way to decrease the amount of disk space used was to compress user data. (We use the term ‘‘user data’’ to refer to the data read from and written to a file, and we use the term ‘‘meta data’’ to refer to accounting information used internally by the file system to represent files.) Our efforts did not stop there, however. We designed the file system to allocate disk inodes as they are needed, so that no space is wasted by unused inodes. In addition, we use a variable block size for user data. This minimizes the amount of space wasted by partiallyfilled disk blocks. Our intent in increasing the robustness of the file system stemmed from our belief that users of other desktop systems (such as MS-DOS) would routinely shut their systems down merely by powering off the computer, instead of using some more gradual method. As it turned out, our eventual choice of file structure required us to build robustness in anyway. From the outset, we realized that any file system that added another level of data processing would probably be slower than other file systems. Nevertheless, we believed that this would not be noticeable on most systems because of the disparity between CPU and disk I/O speeds. In fact, current trends indicate that this disparity is widening as CPU speeds increase at a faster pace than disk I/O speeds [KAR94]. Most systems today are bottlenecked in the I/O subsystem [OUS90], so the spare CPU cycles would be better spent compressing and decompressing data. Our assumptions about typical users led us to believe that users would not know the number of inodes that they needed at the time they made a file system, and some might not even know the size of a given disk partition. We therefore endeavored to make the interfaces to the file system administrative commands as simple as possible.