Messages in this thread | | | From | shapj@us ... | Date | Sun, 20 Jun 1999 16:29:20 -0400 | Subject | Re: Fw: Some very thought-provoking ideas about OS architecture. |
| |
** MOTIVATION FOR TRANSPARENT PERSISTENCE
There are strong (even religious) arguments for and against transparent persistence. In EROS, the design assumption is that mission critical programs are broken into separate processes for reasons of protection and fault containment. This leads to two design challenges:
1. How to avoid recreating them if the system crashes 2. How to keep them mutually consistent.
The second is complicated by the fact that no single user has the authority to interact with (never mind examine) all of the processes involved. Some, for example, are privileged.
The answer to the first is to make processes persistent.
The answer to the second is transactions; the question is what granularity the transactions should be done at. Here are the options:
1. Process-managed (explicit) transactions. Each process tracks its own state, saves what it needs to, and engages in traditional transactions with other processes when it needs to in order to remain consistent. There are two problems with this approach:
a.) Overhead is prohibitive. Things rapidly converge on requiring every operation to be transacted, at which point you are paying a lot of overhead to do the same thing everywhere, and you should begin to consider centralizing the function. The Vino folks are very proud of their in-kernel transaction overheads and rollback mechanisms, and their implementation is actually quite good. They add a factor of over 100X to every kernel operation. On this basis, I argue that this approach is prohibitive.
b) It doesn't work. Once you introduce transactions, things are subject to rollback. This introduces a security problem. If I share a service with a sensitive application (e.g. we indirectly share the X server), then by rolling back a transaction perniciously I can cause the sensitive service to alter its behavior and violate its contracts with third parties.
2. System-managed transactions at process granularity. In this design, the system keeps track of which processes have communicated. Whenever a process commits, everything causally prior to it is committed. This can be done, and it is worth investigating. Our observation is that all applications share in common the system storage allocator and the login agent(s). Many share the display driver. Given this, our expectation is that the set of things that have to commit converges rapidly on the entire system unless transactions are explicitly managed. This appears to be supported by observations of behavior in EROS and KeyKOS.
3. System-wide (i.e. global) checkpoint. In this design, the entire machine is periodically snapshotted and written to disk. This is the EROS and KeyKOS design. It can be done with very low overhead.
Jonathan S. Shapiro, Ph. D. IBM T.J. Watson Research Center Email: shapj@us.ibm.com Phone: +1 914 784 7085 (Tieline: 863) Fax: +1 914 784 7595
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |