lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.033 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site