C. R. Landau. "The checkpoint mechanism in KeyKOS", Proceedings of the Second International Workshop on Object Orientation in Operating Systems, pp. 86-91, September, 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....found the reliability of orthogonal persistence to be very useful [Lie93] KeyKOS also takes system wide checkpoints to provide persistence. It uses asynchrony heavily to reduce the impact of checkpointing on system response time, and even to migrate checkpoints to tape to create o# site backups [Lan92] Lomet and Weikum s checkpointer is designed to checkpoint database applications that run as the second tier in a three tier system. This application is interesting because databases are In a three tier system, the database itself is the first tier, application specific code run on or near ....

C.R. Landau. The checkpoint mechanism in KeyKOS. In Proceedings of the Second International Workshop on Object Orientation in Operating Systems, pages 86--91, 1992.

....pagers) map page frames read only, copy them to bu ers, write them to backing store, and remap them afterwards. Thus the checkpoint pager can eagerly or lazily (copy on write) checkpoint main memory. The checkpointing mechanism used is heavily in uenced by the mechanisms in EROS [14] KeyKOS [7], and L3 [9] For each physical page frame, we have allocated two disk blocks, an a block and a b block, and a status bit that speci es which of both blocks holds the currently valid checkpointed content of the physical page frame. At regular intervals, the checkpoint server takes a consistent ....

....was an integral part of L4 s predecessor the L3 kernel [9] With L4, however, persistence is not an integral part of the kernel. It is an add on feature that the user may choose to ignore. Other kernels integrating persistence into the kernel include EROS [14] and its predecessor KeyKOS [7]. With EROS, taking a snapshot of the system also includes performing a consistency check of critical kernel data structures. This catches possible kernel implementation bugs, and prohibits these bugs to stabilize in the system. A checkpoint in L4, on the other hand, does not include any critical ....

Charles R. Landau. The checkpoint mechanism in KeyKOS. In Proceedings of the 2nd International Workshop on Persistent Object Systmes (POS2), Paris, France, September 24-25 1992.

....even active programs persistent might largely simplify program construction. Data and programs should automatically survive shutdowns and crashes without that the programs explicitly write all their internal data into files all the time. Such operating systems have been around since decades [Lan92, Lie93, DdBF 94, SSF99] The point that is extremely interesting to us is whether orthogonal persistence can be implemented easily and efficiently on top of the microkernel. In other words: is the microkernel sufficiently general and flexible that persistence does not require special kernel ....

C. R. Landau. The checkpoint mechanism in KeyKOS. In Proceedings of the 2nd International Workshop on Persistent Object Systmes (POS2), pages 24--25, Paris, France, September 1992.

....Figure 7: Flow of objects in the system point migrate approach ensures that the system is always able to recover from the most recent successful checkpoint, even if a failure occurs while taking a checkpoint or performing a migration. The EROS checkpoint mechanism is similar to that of KeyKOS [Lan92], but the use of a circular log makes it more adaptable to runtime load variations. In addition, a circular log structure allows the migrator to proceed incrementally [Gra93] If there are heavy demands on memory, the migrator can move a small number of objects, write a new checkpoint directory, ....

Charles R. Landau. "The Checkpoint Mechanism in KeyKOS," Proceedings of the Second International Workshop on Object Orientation in Operating Systems. IEEE. September 1992. pp 86-91.

....model must extend uniformly to the disk; there should be no translation required at this layer in the memory hierarchy. EROS therefore implements a single level store. The state of the machine is periodically snapshotted and written to the store using an efficient asynchronous checkpoint mechanism [Lan92]. The store is active: processes are included in the checkpoint and are restarted automatically on recovery. This eliminates the need for the startup and shutdown phases of many programs, and reduces the frequency of program fabrication. Perhaps more important, transparent persistence eliminates ....

Charles R. Landau. "The Checkpoint Mechanism in KeyKOS," Proceedings of the Second International Workshop on Object Orientation in Operating Systems. IEEE. September 1992. pp 86-91.

....pages and nodes. Address spaces are constructed as a tree of nodes whose leaves are data pages. A complete process showing all resource types is shown in Figure 1. Barring o ine data forensics, the EROS object and protection model are extended to secondary storage by transparent persistence [10]. This ensures that the security model does not change at the 1 In this paper, we will ignore issues of covert channels. While important, reducing such channels is of interest only when it has been shown that overt channels have been closed. 2 In the interest of brevity, we have omitted from ....

C. R. Landau. The Checkpoint Mechanism in KeyKOS. In Proc. Second International Workshop on Object Orientation in Operating Systems, pages 86-91. IEEE, Sept. 1992.

....mechanisms to ensure a consistent system image in the store include application managed transactions or some form of periodic consistent snapshot of the machine state. For reasons of simplicity and correctness, EROS uses a periodic checkpoint similar to the KeyKOS mechanism described by Landau [28]. 2.2 Design challenges There are five key challenges in architecting a capability system. First, transferring control across protection domain boundaries is expensive unless great care is taken in implementing protected control transfers. By default, no access should be shared across such a ....

....application performance. The difficulty lies in ensuring that the image written to the disk is correct; once committed, a bad checkpoint cannot be undone. The EROS implementation guarantees that a correct state exists on the disk by means of a transparent persistence mechanism evolved from KeyKOS [28]. 3.5.1 Snapshot As in KeyKOS, the EROS implementation takes a periodic snapshot of the entire machine. This state is written to the disk asynchronously. On restart the system proceeds from the previously saved system image. Because the checkpointed image is globally consistent, causal ordering ....

[Article contains additional citation context not shown here]

C. R. Landau. The checkpoint mechanism in KeyKOS. In Proc. Second International Workshop on Object Orientation in Operating Systems, pages 86--91. IEEE, Sept. 1992.

....here in as far as local checkpointing is an essential part of distributed checkpointing and also of certain styles of distributed computation. Virtual time for example relies heavily on local checkpoints for distributed synchronisation. Many application frameworks require a checkpointing service[1,6,7,8,9,10,11,12,13,14,15,18]. Its implementation however, without direct OS support, can incur substantial costs in terms of development time and runtime overhead. On the other hand, OS kernels, be they micro or monolithic, implement process management functions such as scheduling and context switching as efficiently as ....

....Of course there are many variations along this spectrum. In TWOS[19] the programmer must syntactically isolate state variables in the source code, but the framework then performs checkpoints automatically. Note that transparency in checkpointing can lead to noticeable delays. The KeyCOS kernel[8] requires no work from an application framework or a user program. It checkpoints its entire system wide state periodically, but can take twenty seconds or more during which time the entire system is halted and all applications pay the same high price, regardless of need. Checkpointing in ....

LANDAU C.R., The Checkpoint Mechanism in KeyKOS, In Proc. 2nd IEEE International Workshop on Object Orientation in Operating Systems, Paris, September 1992, pp. 86--91.

....back to their home locations. The checkpoint migrate approach ensures that the system is always able to recover from the most recent successful checkpoint, even if a failure occurs while taking a checkpoint or performing a migration. The EROS checkpoint mechanism is similar to that of KeyKOS [Landau92], but the use of a circular log makes it more adaptable to runtime load variations. In addition, a circular log structure allows the migrator to proceed incrementally [Gray93] If there are heavy demands on memory, the migrator can move a small number of objects, write a new checkpoint directory, ....

....to be a significant and useful facility, but it is not clear that they warrant the overhead of the thread abstraction. Future Directions The scalability of asynchronous checkpoint remains an open question. The techniques outlined here, and those implemented by Landau, Frantz, and Hardy in KeyKOS [Landau92] scale to memories of a few gigabytes. The limiting factor is the speed of the mark pass. A variety of techniques can be used to implement the bulk of the mark pass asynchronously, reducing the synchronous snapshot phase down into the range of a few microseconds independent of memory size. With ....

Charles R. Landau. "The Checkpoint Mechanism in KeyKOS," Proceedings of REFERENCES 11 the Second International Workshop on Object Orientation in Operating Systems. IEEE. September 1992. pp 86-91.

....process pre emption (i.e. making a process relinquish the CPU and putting it on the ready queue) can be viewed as a simple form of OS checkpointing. Most operating systems do not implement checkpointing beyond process scheduling. There are a few notable exceptions, such as Unicos [KK89] KeyKOS [Lan92] and fault tolerant Mach [RS95] which implement rollback recovery, and Sprite [OCD 88] which is a distributed operating system that includes process migration as a primitive operation. 2. User level, transparent checkpointing: Here, checkpointing is performed by the program itself. ....

C. R. Landau. The checkpoint mechanism in keykos. In Proceedings of the 2nd International Workshop on Object Orientation in Operating Systems, pages 86--91. IEEE, September 1992.

....model must extend uniformly to the disk; there should be no translation required at this layer in the memory hierarchy. EROS therefore implements a single level store. The state of the machine is periodically snapshotted and written to the store using an efficient asynchronous checkpoint mechanism [Lan92]. The store is active: processes are included in the checkpoint and are restarted automatically on recovery. This eliminates the need for the startup and shutdown phases of many programs, and reduces the frequency of program fabrication. Perhaps more important, transparent persistence eliminates ....

Charles R. Landau. "The Checkpoint Mechanism in KeyKOS," Proceedings of the Second International Workshop on Object Orientation in Operating Systems. IEEE. September 1992. pp 86-91.

....as a commercial venture. The primary aims of KeyKOS were security, reliability and 24 hour availability. KeyKOS is founded on the concepts of capabilities, single level store and a stateless kernel [45] KeyKOS provides reliability and availability primarily through its checkpointing mechanism [59]. KeyKOS runs on both uni processors and multi processors, but not in a loosely coupled distributed computing environment. KeyKOS Kernel Design The KeyKOS kernel can run in as little as one hundred kilobytes of memory, primarily because it is stateless, and thus does no dynamic memory ....

Charles R. Landau. The Checkpoint Mechanism in KeyKOS. In Proceedings of the Second International Workshop on Object Orientation in Operating Systems, pages 86--91. IEEE, September 1992.

....and acts accordingly. Examples of runtime parameters that the user may set are whether to checkpoint or recover from a checkpoint, the minimum interval between checkpoints, and which optimizations to employ. While CLIP is less transparent than checkpointers that require no code modification [12, 13, 21, 24], it imposes minimal effort on the part of the user. There are several more cumbersome tasks that non transparent checkpointers [1, 2, 11, 22] force the user to do that are totally automated in CLIP. First and foremost is stack reconstruction. Nontransparent checkpointers provide the programmer ....

C. R. Landau. The checkpoint mechanism in keykos. In Proceedings of the 2nd International Workshop on Object Orientation in Operating Systems, pages 86--91. IEEE, September 1992.

....= pSegKey pObject) ndx] depth ; Figure 6: The traversal algorithm 5 The Checkpoint Mechanism EROS implements persistence and exogenous fault recovery using the same mechanism: a recoverable checkpoint using a circular checkpoint log. The checkpoint mechanism is similar to that of KeyKOS [Landau92], but the use of a circular log makes it more adaptable to runtime load variations. Before any object may be modified in memory, space is reserved for it in the log. When the dirty object is later written to the disk, it is appended to the log. Object cache misses are satisfied from the log if the ....

Charles R. Landau. "The Checkpoint Mechanism in KeyKOS," Proceedings of the Second International Workshop on Object Orientation in Operating Systems. IEEE. September 1992. pp 86-91.

....pager, can operate over a single application or an arbitrary environment, transparently to the target. By loading a checkpointer in the root virtual machine immediately on top of the microkernel, a whole machine checkpointed system can be created similar to that provided in the kernel by KeyKOS[28] and L3[33] To our knowledge this is the first checkpointer that can operate over arbitrary domains in this way. Checkpointing Algorithm Our checkpointer currently uses a simplistic sequential checkpointing algorithm: to take a checkpoint, it stops all the threads in the child process, saves ....

C. Landau. The checkpoint mechanism in keykos. In Proc. Second International Workshop on Object Orientation in Operating Systems, September 1992.

....operating systems with varying levels of service and transparency [2, 4, 11] Most of them require re linking with the target application in order to intercept appropriate system calls [11] or use shared libraries. Kernel state is inferred from calls to and results of kernel system calls. KeyKOS [8] and L3 [9] have transparent multi process checkpointing, but it is an integral part of both kernels, which makes extracting kernel state simpler. In Fluke, checkpointing is a regular application, and runs only when needed. These systems do more for fault tolerance than our current checkpointer, ....

C. Landau. The checkpoint mechanism in KeyKOS. In Proc. Second International Workshop on Object Orientation in Operating Systems, September 1992.

....under grants CCR 9409496, MIP 9420653 and CDA 9529459, by the ORAU Junior Faculty Enhancement Award, and by DARPA under grant N00014 95 1 1144 and contract DABT63 94 C 0049. transparent checkpointing for uniprocessor programs, and checkpointers such as MIST [4] CoCheck [33] and others [2, 10, 18, 28, 32] provide checkpointing in parallel computing environments. All of the above systems store their checkpoints on stable storage (i.e. disk) since stable storage typically survives processor failures. However, since checkpoints can be large (up to hundreds of megabytes per processor) the act of ....

C. R. Landau. The checkpoint mechanism in KeyKOS. In Proceedings of the 2nd International Workshop on Object Orientation in Operating Systems, pages 86--91. IEEE, September 1992.

....the active state during restart. For example, the operating system descriptor FD of an open file with pathname PN will not be valid across restarts, but PN can usually 1 be used to re open the file returning an equivalent descriptor FD new . Persistence at the operating system level [8] [16], 18] 20] attempts to reduce the external state to an absolute minimum. Network communications still present a problem, however. Note that managing external state of this sort requires the programmer to do extra work. That is, the code cannot be persistence independent. In fact, this is an ....

....be applied to the language used to implement the native code. In general this is impossible because the principle of transitive persistence cannot be applied to a weaklytyped language like C. However, we must mention the alternative approach taken by the persistent operating system community [8] [16], 18] which is essentially to define a machine level semantic model in terms of tables of memory pages. This provides persistence by reachability of memory pages, but leaves it up to each language implementation how to map its semantic model to the memory page abstraction. This can be ....

C. Landau. The Checkpoint Mechanism in KeyKOS, Proceedings of the IEEE Second International Workshop on Object Orientation in Operating Systems, September 1992.

....stage. 3 KeyKOS Features Important to Transaction Processing KeyKOS [2 and 4] is a fault tolerant, object oriented, microkernel operating system. KeyKOS uses capabilities[6] to address objects. KeyKOS provides operating system level protection to its objects. The checkpoint mechanism [5] is the principal way KeyKOS makes data durable or persistent. The system level checkpoint periodically saves the entire state of the system on non volatile storage (i.e. disk) This checkpoint protects all processes, data, files, registers, etc. against the system going down (whether planned or ....

Landau, Charles R., "The Checkpoint Mechanism in KeyKOS", Proceedings of the Second International Workshop on Object Orientation in Operating Systems, IEEE, September 1992, pp 86-91

No context found.

C. R. Landau. "The checkpoint mechanism in KeyKOS", Proceedings of the Second International Workshop on Object Orientation in Operating Systems, pp. 86-91, September, 1992.

No context found.

Landau, C.R., "The Checkpoint Mechanism in KeyKOS" Proceedings of the 2nd International Workshop on Object Orientation in Operating Systems, IEEE, 1992

No context found.

C. Landau. The Checkpoint Mechanism in KeyKOS, Proceedings of the IEEE Second International Workshop on Object Orientation in Operating Systems, September 1992.

No context found.

C. Landau. The Checkpoint Mechanism in KeyKOS, Proceedings of the IEEE Second International Workshop on Object Orientation in Operating Systems, September 1992.

No context found.

Charles R. Landau. The checkpoint mechanism in KeyKOS. In Proc. Second International Workshop on Object Orientation in Operating Systems, pages 86--91. IEEE, September 1992.

No context found.

C.R. Landau. "The checkpoint mechanism in KeyKOS." In Proceedings of the 2 nd International Workshop on Object Orientation in Operating Systems, Sep. 1992.

No context found.

Charles R. Landau. "The Checkpoint Mechanism in KeyKOS," Proceedings of the Second International Workshop on Object Orientation in Operating Systems. IEEE. September 1992. pp 86-91.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC