| J. F. Bartlett. A NonStop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, Dec. 1981. |
....from scratch with builtin migration support [30, 4, 9] In contrast, we provide a fairly straightforward implementation of SC in a generalpurpose OS. The idea of using logs at the OS level for deterministic execution replay can be traced back to early fault tolerant operating systems like NonStop [5] and Auros [6, 7] In the NonStop kernel, a message logging scheme was used to provide single failure fault tolerance with primary backup process pairs. This was probably the first system to use logging on inter process communication channels to ensure deterministic replay at the OS level during ....
J. F. Bartlett. A NonStop Kernel. In Proc. 8th Symp. on Operating Systems Principles (SOSP), 1981.
....paradigm, state logging and replication, recursive restartability, and rollback recovery into a generic extensible framework tailored for high performance network access devices. Duplex is based on the process pair paradigm for fault tolerance that was first pioneered in Tandem s NonStop kernel [2]. A pair of processes primary and backup are used to implement a service that needs fault tolerance. The primary process is responsible for all requests to the service and periodically checkpoints the operations on the device s internal state to the backup process. The backup process acts as a ....
....keeps a persistent record of nondeterministic events, such as changes made to the device configuration. In the event of a failure, the logged events are replayed in their original order to recreate device s prefailure state. Duplex s logging mechanism achieves the best of both pessimistic logging [2, 4] or optimistic logging [11] Pessimistic logging requires the service to block till the log is written to stable storage. Optimistic logging allows the log message to be flushed asynchronously to stable storage while the process goes ahead with other operations. The concept of recursive ....
J. Bartlett. A nonstop kernel. In Proc. 8th ACM SIGOPS SOSP, 1981.
....[51] 5.3 Recovery Virtually all recovery techniques rely on some form of redundancy, in the form of either functional, data, or time redundancy. In the case of functional redundancy, good processors can take over the functionality of failed processors, as in the case of Tandem process pairs [11] or clusters [39] Some forms of recovery use time redundancy and diversity of programming logic (e.g. recovery blocks [7] where the computation of an erroneous result triggers a retry using a different algorithm) but such techniques have had only limited appeal due to their cost of development ....
J. F. Bartlett. A NonStop kernel. In Proc. 8th ACM Symposium on Operating Systems Principles, Pacific Grove, CA, 1981.
....instances also distributed across the cluster. The stub keeps track of the secondary as well as the primary and performs failover as required. The primary sends update deltas to the secondary on transaction boundaries, a scheme originally developed for the Tandem NonStop Kernel s process pairs [16]. Its use in this setting creates some anomalies because the internal state of a stateful session bean is not transactional, thus failure of the primary can result in unexpected roll back upon failover to the secondary. Customers universally prefer this behavior to the more expensive option of ....
J.F. Bartlett. A NonStop Kernel. Proceedings 8th Symposium on Operating Systems Principles. Pacific Grove, CA, December 1981.
....to partial failures is to duplicate all an application s data structures and code. For example, all LOT entries at a particular node would be duplicated at some other node elsewhere in the machine. Any update to one copy of the these LOT entries must be applied to the other copy as well. Refer to [4] for an example of a system which exploits software redundancy to tolerate partial failures. 7.3.7 Support for Transition Logging This thesis has always assumed physical state logging at the access path level. Some DBMS designers may prefer other styles of logging. For example, the ARIES method ....
Joel F. Bartlett. A NonStop Kernel. In Proc 8th Syrup. on Operating System Principles, pages 22 29, December 1981.
....Related Work Availability in computer systems is determined by hardware and software reliability. Hardware redundancy has traditionally existed only in proprietary servers, with specialized redundantly configured hardware and critical software components, possibly with support for processor pairs [1]. Examples include the IBM S 390 Parallel Sysplex [20] and Tandem NonStop Himalaya [9] The IBM S 390 Sysplex supports internal processor checking, hot swap execution, redundant shared disk with fault aware system software for error detection, and fail over restart. For example, every processor ....
Bartlett, J., "A Nonstop Kernel", Proceedings of the Eighth Symposium on Operating Systems Principles, Asilomar, Ca, pp 22-29, Dec. 1981.
....and nancial on line transactional applications. These applications require computer systems to continue functioning in the presence of hardware and software failures. In the past, custom designed, fault tolerant hardware has been used to provide highly reliable and available systems. Tandem [2, 1, 32, 18] and Stratus [33] are examples of such systems. However, custom systems tend to be expensive and do not track technology trends as quickly as commodity hardware. Recent e orts have focused on building fault tolerant systems using clusters of commodity components. The Microsoft cluster service ....
....with the backup through a network. The backup node can still access disk data when the primary fails because dual ported disks are connected to both nodes. A typical way to implement a highly reliable and available system is to checkpoint the application s data periodically to shared disks [1]. When the primary fails, the backup node will reload the checkpoint data from shared disks and continue the application from the most recent checkpoint. Taking checkpoints more frequently generally increases overhead during normal operation, but reduces recovery time by minimizing the amount of ....
[Article contains additional citation context not shown here]
Bartlett et al. A NonStop Kernel. SOSP'81.
....in computer systems is determined by hardware and software reliability. A high level of hardware reliability has traditionally existed only in proprietary servers, with specialized, redundantly configured hardware and critical software components, possibly with support for processor pairs [2], e.g. IBM s S 390 Parallel Sysplex [15] and Tandem s NonStop Himalaya [5] Figure 1 Propagating Memory Errors. Memory errors are detected by lower layers and either corrected or propagated to higher levels of the system, up to applications hardware and firmware operating system JVM Java ....
Bartlett, J., "A Nonstop Kernel", Proceedings of the Eighth Symposium on Operating Systems Principles, Asilomar, Ca, pp 22-29, Dec. 1981.
....CPU cycles. Reference: 371] NonStop The Tandem NonStop System is a distributed computer system designed expressly for on line transaction processing. Fault tolerance is achieved by pairs of processes doing the same work on different processors. Processes communicate by messages. Reference: [372] R R is a distributed database management system. Multisite user transactions are structured in a tree of processes communicating over virtual circuit communication links. Beside the transaction management, distributed deadlock detection protocols are implemented. R is running on multiple ....
J.F. Bartlett, "A NonStop Kernel", In Proc. 8th Symp. on Operating Systems Principles, pages 22--29, Pacific Grove, Ca., December 1981.
No context found.
Bartlett, J.,"A NonStop Kernel," Proceedings of the Eighth Symposium on Operating System Principles, pp. 22-29, Dec. 1981.
No context found.
J. F. Bartlett. A NonStop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, Dec. 1981.
No context found.
J.F. Bartlett. A nonstop kernel. In Proc. of the 8th Symposium on Operating Systems Principles (SOSP), pages 22--29, Asilomar, California, USA, December 1981.
No context found.
J. F. Bartlett. A nonstop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, pages 22-29, Dec. 1981.
No context found.
Bartlett, J.,"A Nonstop Kernel," Proceedings of the Eighth Symposium on Operating System Principles, pp. 22-29, Dec. 1981.
No context found.
J. Bartlett, "A NonStop Kernel", Proc 8th ACM SOSP, Dec. 1981.
No context found.
J. Bartlett. A nonstop kernel. In Proc. 8th ACM SIGOPS SOSP, 1981.
No context found.
J. F. Bartlett. A Non Stop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, pages 22-29, December 1981.
No context found.
J. F. Bartlett. A Non Stop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, pages 22-29, December 1981.
No context found.
J. F. Bartlett. A nonstop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, pages 22-29, Dec. 1981.
No context found.
J. F. Bartlett. A Non Stop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, pages 22-29, December 1981.
No context found.
Joel F. Bartlett. A NonStop kernel. In Proceedings of the Eigth ACM Symposium on Operating Systems Principles, pages 22--29, Pacific Grove, CA, U.S.A., December 1981. ACM SIGOPS. 23.
No context found.
Bartlett et al. A nonstop kernel. Proceedings of the 8th SOSP, October 1981.
No context found.
J. F. Bartlett. A Non Stop kernel. In Proceedings of the 8th ACM Symposium on Operating Systems Principles, pages 22-29, December 1981.
No context found.
J. F. Bartlett. A NonStop Kernel. In Proc. 8th Symp. on Operating Systems Principles (SOSP), 1981.
No context found.
J. Bartlett. A nonstop kernel. In Proc. 8th ACM SIGOPS SOSP, 1981.
First 50 documents Next 50
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