A Persistent System in Real Use - Experiences of the First 13 Years -

✨ Summary

Paper summary

The paper reports thirteen years of operational experience with Eumel and four years with its successor, L3, persistent operating systems developed at GMD and used in educational, commercial, and industrial settings. Their central design principle is that persistence should apply uniformly to data, processes, and, in principle, all system objects. Files are therefore implemented as persistent objects rather than being treated as a special storage abstraction.

Eumel and L3 use virtual address spaces, mapping, demand paging, and copy-on-write techniques to provide persistent dataspaces. Processes and threads are also persistent, allowing program state, stacks, registers, and communication state to survive system restart. Tasks are treated as first-class, autonomous objects that own and control their data. Device-driver tasks are an important exception: because many drivers must remain resident and cannot safely be written to persistent storage, they may be explicitly nonpersistent.

The systems use direct, synchronous inter-process communication based on globally unique task and thread identifiers rather than kernel-managed channels or ports. The L3 security and mediation model, called “clans and chiefs,” redirects communication crossing clan boundaries to a user-level chief, which can inspect and authorize or transform messages. This supports user-defined protection policies, system-version adaptation, remote communication, debugging, and supervision while keeping the kernel mechanism small.

The principal recovery mechanism is the fixpoint: an atomic, system-wide checkpoint containing tasks, threads, address spaces, dataspaces, files, databases, and terminal state. Copy-on-write makes the initial snapshot short; dirty pages are written to backing storage afterward while normal activity continues. Restarting activates the latest valid fixpoint, typically sacrificing only the work performed since that checkpoint. The paper explains how kernel control blocks and interrupted persistent IPC operations are included in recovery, while communication involving transient resident drivers must be aborted and re-established.

The reported experience is mixed but substantially positive. Fixpoint recovery handled many software failures, power failures, and hardware-related faults, commonly limiting data loss to approximately the preceding five minutes. However, persistent checkpointing can also preserve corruption caused by severe kernel-level errors, particularly defects in memory management, paging, and concurrent block reclamation. The authors emphasize that achieving production quality required extensive real-world use by the developers themselves, careful debugging, and a willingness to balance stability against performance and new hardware support.

The authors argue that persistence need not be prohibitively expensive because most required mechanisms—virtual memory, address spaces, paging, and mapping—are already common in timesharing systems. The principal additional cost is fixpointing, which requires backing-store capacity, extra paging activity, and memory headroom for copy-on-write. Their measurements indicate that L3 could provide fast IPC, inexpensive dataspace operations, and practical multiprogramming performance on contemporary 386 and 486 hardware.

Influence on later research and industry

The paper documents that Eumel/L3 influenced the BirliX operating-system design. Later persistent-system research also cited the paper directly. The Mungi work on persistent object systems in a single address space cites it as prior work and develops related techniques using persistent virtual memory, shadow paging, copy-on-write, and user-level pagers. (os.itec.kit.edu)

The EROS capability-system research likewise cites the paper and explores transparent persistence, persistent process state, and consistent checkpointing in a capability-based microkernel. This provides concrete evidence that the Eumel/L3 experience informed subsequent research on recoverable operating systems, although the available sources do not establish that the paper alone caused those later developments. (flint.cs.yale.edu)

The paper’s publication metadata is corroborated by the KIT publication list and the proceedings record, which identify the IWOOOS event as taking place in Asheville on December 9–10, 1993. (os.itec.kit.edu)