Fault tolerance under UNIX

Reviewer: Paul Siegel

After many years of relatively quiet use in Bell Labs, universities, and a few commercial development centers, the UNIX operating system has recently become more popular. Its portability is a major asset: applications developed on a machine running UNIX can generally be made to run on another machine running UNIX with very little effort, even if the two machines are made by different manufacturers. Around the time IBM came out with the System/360 in the 1960s, users began to balk at the necessity of rewriting all their applications whenever they changed hardware. This reluctance was heightened when CP/M, followed closely by MS-DOS, made thousands of applications portable across many microcomputers of different manufacture. Meanwhile, UNIX had been implemented on a variety of machines of widely differing architectures. Although UNIX is much more powerful than MS-DOS, it ran principally on minis. As hardware prices fell and interest grew, however, UNIX became available on the largest machines as well as on micros, Simultaneously, the market for fault tolerance began to increase. First launched in a big way by Tandem in 1977, fault tolerance has virtually become a requirement in certain application areas, particularly transaction processing. As other companies came into this competitive market, some failed, including Auragen Systems, which tried to capitalize on the advantages of UNIX and fault tolerance to create a product for the transaction processing market. Nixdorf has apparently taken that product, revised it, and produced TARGON/32—a distributed, fault-tolerant version of UNIX. I enjoyed reading this paper because my background is in fault tolerance and UNIX, and I have followed the evolution of both with great interest. Despite its occasional lapses into UNIX jargon, I think that this paper would enlighten anyone who had an operating system background. It discusses some history, how the goals of TARGON/32 differ from those of other currently available systems. The authors then cover TARGON/32's architecture, server processes, process families, interprocess communication, backup and synchronization of user processes and peripheral servers, crash detection and recovery, and finally the impact of fault tolerance on performance. I was surprised to learn that the performance penalty of fault tolerance in the TARGON distributed architecture is only ten percent over non–fault-tolerant processes. I found a few minor errors that I wish had been corrected: :9BNot all TOCS readers are necessarily conversant with the problems of fault tolerance. Therefore, the authors should have pointed out that restoring a module to service can be an expensive operation, arguing against automatic restoration of modules immediately after they become available. The few remaining assumptions about the reader's understanding of UNIX internals such as inodes and index blocks could easily have been removed. TARGON/32 is an asymmetrical multiprocessor system, but the authors never examine the performance impact of the asymmetry. The authors do not discuss how unrelated processes that share such resources as memory and semaphores are backed up. These are minor points. In general, I appreciate the value of this paper and the system it describes. I am in favor of any work that helps integrate UNIX with modern system requirements.