Experiences with the Amoeba distributed operating system

Reviewer: Jason Gait

Amoeba is an ambitious distributed operating system implemented on a widely scattered ensemble of machines. Amoeba aspires to be much more than a conventional network operating system in which each machine retains its visibility and must be dealt with independently. The authors do not mention the positive side of network operating systems and the primary reason for their evolution: the preservation of local autonomy and control. The Amoeba system architecture presupposes a workstation for each user where tasks that require fast interactive responses are carried out. The heart of Amoeba is the concept of a pool of processors. Each machine in the pool is allocated dynamically to a specific program and is returned to the pool when the program finishes. Conventional operating system services, such as directory and file services, are provided by dedicated machines that are responsible for specific services. Some Amoeba machines are dedicated as gateways between separated local area networks, which are connected via one of several wide area technologies. Amoeba gateways are responsible for hiding grubby wide-area details from the rest of the system. The Amoeba machines all run the same small kernel, responsible only for multithread processes, IPC, and I/O. Amoeba does not support virtual memory. The Amoeba presentation layer is object-based. Each Amoeba object, such as a directory or file, is managed by a server. Amoeba locates a server by broadcasting a request for service within the local area; local servers respond with their address. A service is located across a gateway by virtue of having published its address at the gateway. Unwillingly, it seems, Amoeba attempts to realize a UNIX system call interface. Amoeba does not support the signal, fork, or exec system calls, but it has an adequate infrastructure for 100 common utility programs that partly define a UNIX user environment. Local network IPC performance seems to be roughly comparable to the V-kernel and is superior to most protocol-heavy UNIX IPC. Amoeba implements a system-wide file system that incorporates location transparency. The important file server for Amoeba, optimized for high performance, is the Bullet Server. The Bullet Server stores files in 30-kbyte extents, both on disk and in memory, and moves files about the network as integral objects. Amoeba does not incorporate page caching in the network. The Bullet Server never overwrites a file, but creates a new version whenever a file is updated. Old versions of files can only be explicitly deleted by their owners. The efficiencies in the Bullet Server come from two optimizations: at boot time the Bullet Server copies the file system metadata into memory and keeps it there, and files no larger than 30 kbytes are retrieved from disk in one access and sent across the network in one message. The Bullet Server only understands capabilities; a separate name server translates user object names (represented as ASCII strings) into capabilities (represented as 128-bit numbers) that the Bullet Server uses to access files. In the authors' evaluation of the successes of Amoeba, they express satisfaction with the object system, capabilities, the performance of IPC, directory service, file service, the basic design of the wide area protocols, the processor pool, and overall performance. They express dissatisfaction with the IPC packet acknowledgment protocol, lack of support for multicast, asynchronous IPC, non-preemptable threads, lack of an IPC timeout protocol, the performance of the wide-area protocols, the quality of the UNIX emulation, and the lack of support for link encryption. They promise that the next version of Amoeba will correct these perceived problems. The authors are undecided about some areas, including the lack of support for virtual memory, the split between directory service and file service, and the lack of support for process migration. Early on, Amoeba realized a small, efficient window management system. The authors made a reluctant, too hasty and too commercial, decision to switch to X-W indows. I have a couple of additional reservations about Amoeba. I am not content with the decision to dedicate physical machines from the pool of processors to single (multithreaded) programs. This seems to be a waste of CPU bandwidth, especially when the MIPS rating of candidates for the pool of processors is rising exponentially and virtual machine technologies are well known. In the past, distributed systems of all flavors have optimized for the local case. Amoeba optimizes for the remote case under the assumption that remote operations will be more common than local operations in an environment where remote operations are adequately supported. Although the authors are pleased with this optimization, to me it is a Scots verdict.