The Cedar file system

Reviewer: Edward A. Feustel

The Cedar file system is part of the Cedar programming environment at Xerox Palo Alto Research Center. It was designed to realize the following goals: high-performance remote file access by workstations, low amortized system cost, high reliability, high availability, information protection, the ability to scale the size of the system, and coordination of concurrent access by workstations on a local area network to shared data. First, the paper provides a tutorial on the three types of file systems: remote-disk systems, block-level-access systems, and file-level-access systems. The Cedar file system transmits entire files rather than blocks. Second, the paper provides a tutorial on three methods of cache consistency when the caches are on separate workstations and contain the file in use. Next, the authors proceed to discuss the Cedar file system and the features that help that system satisfy the goals outlined above. Two unusual ideas caught my attention. The first is that data objects are immutable: that is, once created, they are never changed. Whenever a user writes a data object, its name, the server ID, and a new version number are used to identify it. The second is that the binding (attachment) between file names and data objects is variable instead of fixed. Thus, when a new file object is created, the user name for the file remains the same, but the name is re-bound to the new data object. The file system has some of the properties of pure LISP with persistent objects. Objects are created by the user. When the user is finished with the object, his or her name for it is unlinked from the object. If no more names refer to the object, the space occupied by the object is collected and reused. All references to the file are by value and produce no side effect on that object. The paper goes on to describe some of the file system operations and an application DF, which provides an environment for the development and management of large software systems. DF permits the capture of the total state of the system at the time of an activity. It does this by recording the attachments at the time the activity was done and capturing the names of the input file, output files, compilers, and so on. The authors next discuss the implementation and performance of the system. In this section the many advantages of immutable files are described. These benefits extend from simplified requirements for locking and replication to policies used in caching information. Very brief performance data are provided to motivate the exposition of the design. In the discussion of the file system from the perspective of having used it over a period of years, the authors reflect on how they met some of the goals listed above and how they were unsuccessful in meeting some of the others. They mention their pleasure in the fact that “a single file server running on an Alto can support 20 or more Cedar programmers using Dorado workstations, which are each eight times faster than an Alto.” Their final paragraph sums up the paper: “In retrospect, the combination of the Cedar File System's semantics with the higher-level tools for maintaining consistent versions of shared software subsystems has worked extremely well. Given sufficient local storage, we now believe it is unnecessary in this application to have shared file servers that provide mutable files, block-at-a-time access to files, longterm locks, or transactions.”