R. Strom, S. Yemini, and D. Bacon. A recoverable object store. In Proceedings of International Conference on System Sciences, Vol. 2, 215-221, 1988.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....several techniques for designing file servers that assist applications during failure recovery have been investigated. For instance, versioning file systems eliminate the need for read logging by ensuring that a file version read by an agent prior to failure will be available during recovery [28]. Similarly, implementation of stable storage, using special hardware, such as non volatile RAM [6, 33] or a specialized operating system, such as the Rio file cache [9] in the memory sub system at the server eliminates the need for synchronous writes to disks. Unfortunately, neither of these ....

R. E. Strom, S. A. Yemini, and D. F. Bacon. A recoverable object store. In Proceedings of Hawaii International Conference on System Sciences (HICCS-88), pages II--215--II--221, January 1988.

.... to illustrate how transient software failures can be recovered by automatic environment diversity, and how permanent software failures can also be recovered by intro3 Strom et al. described a disk checkpoint manager for checkpointing disk files in a self recovering distributed operating system [3]. In contrast, our approach has focused on developing application level techniques that can be incorporated into existing standard Unix applications. OS environment OS environment OS environment OS environment state Volatile state Persistent state Volatile state Persistent Volatile state state ....

....be generated at unlink( If a failure occurs later on, the shadow copy and the recorded size can be used to restore fileapp to have both correct contents and correct size. A natural optimization to further reduce both run time and space overhead is to perform the shadowing on a page by page basis [3]. 4 Bypassing Premature Software Exits Design diversity [15, 16] and data diversity [17] are two well known approaches to software fault tolerance. In order to recover from a software failure, the design diversity approach executes a different program (implementing the same function) on the same ....

R. E. Strom, , S. A. Yemini, and D. F. Bacon, "A recoverable object store," in Proc. Hawaii International Conference on System Sciences, pp. II--215--II--221, Jan. 1988.

....roll back if a failure occurs in the system. For example, a printer cannot roll back the effects of printing a character; an automatic teller machine cannot recover the money that it dispensed to a customer; a deleted file cannot be recovered (unless its state is included as part of the checkpoint [166, 191]) It is therefore necessary to ensure that the outside world perceive a consistent behavior of the system despite failures. Thus, before sending output to the outside world, the system must ensure that the state from which the output is sent will be recovered despite any future failure. This is ....

R. E. Strom, , S. A. Yemini, and D. F. Bacon. A recoverable object store. In Proc. Hawaii International Conference on System Sciences, pages II--215--II--221, January 1988.

.... time fault (or incorrect guess) occurs. 2 Optimistic Recovery Our approach to recovery is based upon optimistic recovery [6] enhanced by optimizations to reduce the amount of logging [5, 1] and extensions which incorporate the filesystem and other external components into the recovery process [7, 8]. In optimistic recovery, we guess that processors do not fail; specifically, for every non deterministic event (usually a message) we guess that there will not be a failure before that message has been asynchronously logged. Each of these guesses is assigned a number, and each process records ....

STROM, R. E., YEMINI, S. A., AND BACON, D. F. A recoverable object store. In Hawaii International Conference on System Sciences (1988), IEEE CS.

....absence of failure will behave identically (except for stutter) in the presence of failure without having to be rewritten. 2. 2 Overview of Algorithm OR is described in detail in Strom and Yemini s paper[18] Optimizations to reduce the cost of checkpointing and logging are described in other papers[17, 1, 19, 20]. OR is based on backwards error recovery[15] A recent consistent state of a system is obtained by restoring recent states of each recovery unit such that for any communication link from RU A to RU B, 1) there are no missing messages messages sent by A but not received by B, and (2) there are ....

....committed data, but it is also possible to view the file system as the internal state (volatile storage) of an RU corresponding to the file server. There are optimizations to avoid logging all messages to a file server[1] and to avoid copying the whole file system in order to take a checkpoint[20]. The current implementation does not support recovering the state of the UNIX file system. 3.1.4 Piecewise Determinism OR presupposes that each RU is piecewise deterministic. For a single threaded Mach task without shared memory, this is straightforward. The computation and most of the system ....

[Article contains additional citation context not shown here]

Strom, R. E., Yemini, S. A., and Bacon, D. F. A recoverable object store. In Hawaii International Conference on System Sciences (KailuaKona, HI, Jan. 1988), vol. II, pp. 215--221.

No context found.

R. Strom, S. Yemini, and D. Bacon. A recoverable object store. In Proceedings of International Conference on System Sciences, Vol. 2, 215-221, 1988.

No context found.

R. E. Strom, S.A. Yemini and D. F. Bacon. "A recoverable object store." In Proceedings of the Hawaii International Conference on System Sciences, pp. II-215---II221, Jan. 1988.

No context found.

Strom, R.E., et al. "A recoverable object store". IBM Watson Research Ctr., 1988.

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