A Dialogue on Persistence

Part III 💬 Dialogue OSTEP pp. 417–418 · ~4 min read

The same fruit that opened Part II is back, and what threatens it now is not other hands but time.

Why this matters

The professor reads out the dictionary — “obstinate continuance … in spite of difficulty or opposition” — announces that the word means something different here, and then describes exactly that: keeping information despite crashes, failed disks and power cuts. The sense being dismissed is the one the part is about.

The third pillar begins the way the others did — with the professor, the student, and (the student insists) a peach.

Professor:And thus we reach the third of our four… err… three pillars of operating systems: persistence .
Student:Did you say three pillars, or four? What’s the fourth?
Professor:No. Just three, young student, just three. Trying to keep it simple here.
Student:OK, fine. But what is persistence, oh fine and noble professor?
Professor:You know it in the traditional sense already — as the dictionary says: “a firm or obstinate continuance in a course of action in spite of difficulty or opposition.”
Student:Kind of like taking your class: some obstinance required.
Professor:Ha! Yes. But here it means something else. Imagine you’re in a field, and you pick a —
Student:(interrupting) I know! A peach! From a peach tree!
Professor:I was going to say an apple. Oh well; we’ll do it your way. You pick many peaches, and you want them to last a long time — winter is hard and cruel in Wisconsin. What do you do?
Student:Lots of things! Pickle it, bake a pie, make jam. Fun!
Professor:Fun? Maybe. But certainly a lot more work to make the peach persist. And so it is with information: making it persist — despite computer crashes, disk failures, and power outages — is a tough and interesting challenge.

The peach, and the point: raw things perish; preserved things persist — and the same is true of your data.

the peach🍑fresh → rots by winter🫙🥧jam / pie / picklepreserved → lastsextra work buys survival→your datain memory onlycrash / power loss → goneon disk / FS 💾persists across crashesI/O devices, disks, file systems, journaling — the work of Part III
Student:Nice segue; you’re getting quite good at that.
Professor:Thanks! A professor can always use a few kind words.
Student:I’ll try to remember that. Time to stop talking peaches and start talking computers?
Professor:Yes, it is that time…

If you remember only three things

  • Every hazard named is one the program takes no part in. Part I’s problems arrived because a program did something and Part II’s because two did something at once; a crash, a failed disk and a power cut are none of a program’s doing.

  • This stack is climbed from the bottom. Part I named the abstraction and then built it, while here the device comes first and files arrive several chapters later — what can be promised depends on what the hardware will agree to.

  • The student answers with a list rather than a method. “Pickle it, bake a pie, make jam” — three ways to keep one peach, and the part ahead has the same shape: several defences, each good against a different way of losing things.

The road through Part III

Persistence is a whole stack, and we’ll climb it from the metal up:

I/O devicesch36›HDD · SSDch37·44›RAIDch38›File systemsch39–41›Journaling · LFSch42–43›Data integritych45›Distributed FSch47–50from the raw device up to file systems that survive crashes and span networks

Check yourself: what persistence means

1.In the systems sense, what does persistence mean?

2.How does preserving a peach (jam, pie, pickle) map to the systems idea?

3.Why is achieving persistence a genuinely hard challenge (not just 'write the data down')?

4.Persistence is which of the OS's pillars, and how many are there in this book?

4 questions