[coyotos-dev] Explicit Persistence Considered Harmful

Jonathan S. Shapiro shap at eros-os.com
Mon Aug 18 15:35:50 CDT 2008


As you all know, I have gone back and forth on persistence. I'm tilting
at this windmill once again, and trying to get my thoughts organized.
Help would be appreciated.

DISTINCTIONS:

By "explicit persistence", I mean the type of persistence in which
programs write things down explicitly. This is the type of persistence
used in (e.g.) UNIX.

By "implicit persistence", I mean the type of persistence used in
KeyKOS, EROS, Coyotos, and CapROS. This includes the state of active
processes.

It has been argued that there are advantages in system bootstrap. On
reflection I do not agree. Bootstrap is a very special case. Removing
checkpoint from a system does not preclude loading the system from a
hand-constructed image. The two issues are orthogonal.


ADVANTAGES OF IMPLICIT PERSISTENCE

1. The main high-level advantage to persistence is the ability to
organize applications into multiple, cooperating programs. In the event
of system failure, these programs have no need to re-coordinate their
state.

2. Capability safety requires that one maintain a type partition between
data and capabilities. If persistence is not implicit, then capabilities
that reference server-implemented objects are effectively severed by
restart. This means that:

  a) Some form of file system comes to be required, or
  b) Some form of re-connection protocol implemented by a trusted
     service becomes necessary.

Neither is impossible, but both are complex and awkward.

3. There is no need for transactional storage for the purpose of safety
maintenance in an implicitly persistent system. Transactions may be
desirable for other reasons.

4. Authority is uniquely associated with *instances* of applications.

5. It is argued that persistence eliminates the need for serialization
support. This argument is wrong, both because of cross-machine data
exchange and because of recovery requirements.


DISADVANTAGES OF IMPLICIT PERSISTENCE

1. It is exceptionally hard to implement "notify on last close"
semantics. This can lead to a slow (or rapid) accretion of unreferenced
storage. It is particularly acute in servers that provide large amounts
of shared, read-mostly state to multiple clients (e.g. font servers). It
is also problematic when programs exit uncleanly.

2. A surprising amount of machinery is required in the OS to support
implicit persistence. In particular it impacts the memory management
system.

3. There are recoverability issues associated with implicit persistence.
It is actually important that buggy program instances die and reload
their state. In consequence, the argument that persistence eliminates
the need for explicit storage seems dubious.


OTHER THOUGHTS

I used to believe that moving away from implicit persistence implied
moving towards a transactional file system model. I no longer believe
this. What I now believe is that (a) this is an issue for updates
involving multiple files, and (b) the problem is that said files are
files rather than tables in a database.


shap



More information about the coyotos-dev mailing list