§2.4–2.7Persistence … Summary

One piece left. CPUs compute and memory remembers — but only while the power is on. The third piece is about what survives.

2.4 Persistence

System memory is volatile: DRAM loses its contents when the power goes away or the system crashes. So we need hardware and software to store data persistently persistence Keeping data safe across power loss and crashes, via I/O devices and the software that manages them. defined in ch. 2 — open in glossary — users care rather a lot about their data.

The hardware is some form of I/O device i/o device Hardware that connects the computer to the outside world or stores long-lived data (disks, SSDs). defined in ch. 2 — open in glossary : in modern systems, a hard drive is the common home for long-lived information, with solid-state drives (SSDs) making headway. The software is the file system file system The OS software that manages persistent data on storage devices. defined in ch. 2 — open in glossary — the part of the OS responsible for storing user files reliably and efficiently on disk.

One big difference from the first two pieces: the OS does not create a private, virtualized disk for each application. Files are meant to be shared. Think about how a program gets born:

Here is a program that creates a file containing “hello world” — the io.c of Figure 2.6:

#include <stdio.h>
#include <unistd.h>
#include <assert.h>
#include <fcntl.h>
#include <sys/types.h>

int main(int argc, char *argv[]) {
    int fd = open("/tmp/file", O_WRONLY|O_CREAT|O_TRUNC,
                     S_IRWXU);
    assert(fd > -1);
    int rc = write(fd, "hello world\n", 13);
    assert(rc == 13);
    close(fd);
    return 0;
}

Figure 2.6: A Program That Does I/O (io.c)

The program makes three calls into the operating system: open() opens and creates the file, write() writes data into it, and close() says no more writing is coming. These system calls are routed to the file system, which handles the request and returns an error code. Step through what one of those calls actually involves:

What the OS does to actually write to disk is (the book warns: close your eyes, it’s unpleasant) a fair bit of work: figure out where on disk the new data will live, track it in the file system’s own structures, and issue I/O requests to the storage device through a device driver device driver Code in the OS that knows how to deal with a specific hardware device. defined in ch. 2 — open in glossary — OS code that knows the low-level device interface and its exact semantics. That the OS wraps all this behind a standard, simple interface is one more reason it gets called a standard library.

Two performance-and-reliability details, both foreshadowing Part III:

• For performance, most file systems delay writes, hoping to batch several into fewer, larger disk operations.
• For crash safety, most file systems use an intricate write protocol — journaling or copy-on-write — carefully ordering the writes so that if a crash lands mid-sequence, the system can recover afterward.

2.5 Design Goals

So an OS virtualizes physical resources, wrangles concurrency, and stores data safely. What should guide how it’s built? Building systems means making trade-offs, and these are the recurring goals:

2.6 Some History

Operating systems accumulated their good ideas over decades. The book’s short tour, era by era:

Early operating systems: just libraries. At first the “OS” was a set of commonly-used routines (low-level I/O handling, say) so that not every programmer wrote them from scratch. One program ran at a time, chosen and loaded by a human operator — this was batch processing batch processing Early non-interactive computing: an operator ran queued jobs in batches. defined in ch. 2 — open in glossary : jobs queued up and run in batches, never interactively. Computer time was simply too expensive to let a person sit at the console.

Beyond libraries: protection. The realization that OS code was special — it controls the devices — led to the invention of the system call, pioneered by the Atlas computing system. Rather than calling OS routines like any library function, a special pair of hardware instructions and hardware state make entering the OS a formal, controlled act. Programs run in user mode user mode The restricted hardware mode applications run in — no direct I/O or privileged operations. defined in ch. 2 — open in glossary , where the hardware restricts what they can do — no raw I/O requests, no touching arbitrary physical memory. A system call starts with a trap trap A hardware instruction/event that jumps into a pre-registered OS handler while raising the privilege level. defined in ch. 2 — open in glossary instruction: the hardware jumps to a pre-registered trap handler and simultaneously raises the privilege level to kernel mode kernel mode The privileged hardware mode in which the OS has full access to the machine. defined in ch. 2 — open in glossary , where the OS may do anything it likes. When done, the OS uses return-from-trap return-from-trap The instruction that reverts to user mode and resumes the application where it left off. defined in ch. 2 — open in glossary to drop back to user mode and hand control back exactly where the program left off. (You watched this cycle in the widget above.)

The era of multiprogramming. Minicomputers (like DEC’s PDP family) made computers affordable enough that every workgroup — not every corporation — could have one, and developer activity exploded. Multiprogramming multiprogramming Keeping several jobs in memory and switching between them (especially during I/O) to raise utilization. defined in ch. 2 — open in glossary became standard: load several jobs in memory and switch among them, especially when one waits on slow I/O. Why let the CPU idle? This forced the big conceptual advances — memory protection, and correctness in the face of interrupt-driven concurrency (a problem you met in the previous section). The practical milestone of the era: UNIX, from Ken Thompson and Dennis Ritchie at Bell Labs.

The modern era. Then came the PC — cheaper, faster, for everyone, and at first a great leap backwards for operating systems. DOS didn’t think memory protection mattered; a bad program could scribble over everything. Mac OS 9 and earlier scheduled cooperatively, so one program stuck in a loop took the whole machine down. It took years for the minicomputer lessons to reach the desktop: macOS put UNIX at its core, Windows NT was Microsoft’s own great leap forward, and today’s phones run OSes closer to 1970s minicomputer systems than to 1980s PCs — thank goodness.

2.7 Summary

You now know what an OS does: it virtualizes physical resources, handles the hard problems of concurrency, and stores data persistently. What this book deliberately leaves out: networking (take the networks course), graphics devices (graphics course), and deep security (security course — though protection between programs runs all through Part I). What’s ahead: virtualization of the CPU and memory, concurrency, and persistence — most of it, the book promises, quite cool.