Persistence Pros and Cons

[Jonathan S. Shapiro]

This note is an attempt to answer "What is EROS-style persistence good
for?"

We've already talked about the "coolness" factor. Kick out the plug, put
it in, and just keep going. Very marketable. Good to have. Probably a
sufficient reason to do it, but not a *technical* motivation.

We've also talked about something that *doesn't* change. Persistence
does not eliminate the need for applications to be able (de)serialized
data. You still need to be able to write data out in interchangeable
format for cut/paste, write to floppy, transmit by email, and so forth.

Here is what persistence buys us if we choose to adopt it:

1. A Sane Theoretical Story For Security

Any story about a system being secure amounts to:

  the system starts in a secure state, and then
  execution proceeds be performing a sequence of consistent updates
    to the system state, each of which transitions from an existing
    globally safe state to a new globally safe state.

Persistence makes the second part quite literal. This is not easy to
explain to users, but it does seem to work. Nice to have, not a reason
for Hurd to be persistent.

2. Persistence Turns the File System Into An Application

In a persistent system, the disk is basically a pool of undifferentiated
blocks. Major pieces of the system can exist perfectly sensibly without
having anything that you or I would recognize as a file system. This is
useful for three reasons:

  A) It lets us set up some fairly complex code and trust relationships
     in ways that are very hard to break, and

  B) It simplifies the core system, and

  C) It improves performance.

All of these are good reasons to have persistence.

3. Persistence Turns the File System Into An Application

Saying "boot the system with persistence turned off" is exactly like
saying "boot the system without the disks attached."

4. Persistence Sits Underneath Separation of Authority

Persistence is how an application can hold authority that you didn't
give it. This is how things like the EROS login system can work without
needing anything remotely like a superuser authority.

This is a good reason to have persistence.

5. Persistence Facilitates Transactions

Because of persistent recovery, an application can rely on the fact that
code runs to completion. You can start an algorithm, take a checkpoint,
fail, restart, and know that the algorithm will continue.

Concrete example: you can guarantee that things like passwd and shadow
will both be updated.

This property is more important than it sounds. It is amazing how tricky
disk manipulation code can get if you want recoverability.

6. Persistence Makes Real-Time Tricky

Persistence does introduce some new sources of page fault variance into
the system. For soft real-time, I think we know how to deal with these
sufficiently well. For hard real-time, I don't think so.

7. In an Odd Way, Persistence is Lower Level

This is kind of strange, but a persistent system snapshot feels a lot
like a ROM image. You can take an EROS-style system image, drop it on a
ROM, boot it, and simply turn off the checkpoint logic. Figuring out how
to do this in file system based designs always makes my head hurt. This
may just be my own quirk.

8. Persistence makes fsck unnecessary.

No need for it, because the disk subsystem is transacted to begin with.


I think that in the end persistence is a matter of taste. It has allowed
us to structure the EROS system very differently, and we have found the
results to be powerful. Having said that, it is a struggle to articulate
*why* this should be so, and I am not satisfied that I have done so.


shap