A Look Back at the Sprite Network OS

Author: John Ousterhout
Affiliation: Computer Science Division, Department of EECS, University of California at Berkeley

For eight years, I had the privilege of leading the development of Sprite, a research-oriented operating system. The project was launched in the Fall of 1984 by myself and four graduate students. Our primary motivation was the observation that contemporary operating systems were failing to adequately address the needs of local-area networks (LANs).

The Motivation for a New Approach

At the time, networking capabilities were typically integrated as an afterthought added in a "quick and dirty" manner to kernels originally designed for standalone operation. This led to a fragmented experience where networked workstations lacked cohesion.

Our objective was to "do networking right." By constructing a new kernel from the ground up, we aimed to make a cluster of workstations function as a single cohesive system, where both processing power and storage were distributed uniformly. We wanted the scalability of a network with the administrative simplicity of a traditional time-shared system.

---

Key Milestone 1: The Network File System

Sprite's first major achievement was its network file system. It proved that a user-friendly model could coexist with high performance.

• Transparency: The network is completely hidden; users interact with files as if they were local.
• Uniformity: Even I/O devices are accessed consistently across the network.
• Extensibility: Developers can expand the system using pseudo devices and pseudo file systems by implementing specific naming and I/O protocols.
• Performance: Through the use of aggressive file caching, Sprite maintained the title of the fastest network file system available for five years post-launch.

---

Key Milestone 2: Transparent Process Migration

Sprite implemented a mechanism to move active processes between workstations without interruption. This allowed a single user to leverage the collective CPU power of the cluster.

The Migration Workflow:

• Identify idle workstations in the cluster.
• Migrate processes to these idle machines to increase throughput.
• Monitor owner activity.
• Evict migrated processes if the workstation's owner returns (to ensure no latency for the primary user).
• Re-route evicted processes to another idle node or back to the home machine.

This capability resulted in significant performance gains. For instance, common tasks like recompilation saw a speedup of: $\text{Performance Gain} \approx 4\times$

Unlike most research projects, Sprite's process migration was utilized daily by a large community of users.

---

Key Milestone 3: The Single System Image (SSI)

Beyond files and processes, Sprite was designed to feel like one machine. This is achieved through a unified administrative layer:

Unified Components:

1. One root partition.
2. One password file.
3. One login database.
4. One swap area (integrated into the network file system).

For example, running the finger command provides information on all users across the entire cluster, regardless of which specific workstation the user is currently logged into.

Scalability and Architecture

Administration scales linearly; managing 50 machines is roughly as simple as managing 10. Adding a new machine is as effortless as creating a new user account. Furthermore, Sprite supports heterogeneous architectures within a single cluster. We achieved this by separating data into two categories:

struct SystemInfo {
    ArchitectureIndependent data; // Visible to all nodes
    ArchitectureSpecific data;    // Used only by matching hardware
};

This framework simplifies cross-development while ensuring each machine utilizes the correct hardware-dependent information.

---

Key Milestone 4: Log-Structured File System (LFS)

Sprite's fourth major contribution was the introduction of the log-structured file system (LFS), which demonst...