LOCUS (operating system)

LOCUS
Developer	UCLA
OS family	Unix
Working state	Historic
Source model	Closed source
Kernel type	Monolithic kernel
License	Proprietary

LOCUS is a discontinued distributed operating system developed at UCLA during the 1980s. It was notable for providing an early implementation of the single-system image idea, where a cluster of machines appeared to be one larger machine.[1]

A desire to commercialize the technologies developed for LOCUS inspired the creation of the Locus Computing Corporation which went on to include ideas from LOCUS in various products, including OSF/1 AD and, finally, the SCO–Tandem UnixWare NonStop Clusters product.

Description

The LOCUS system was created at UCLA between 1980 and 1983, initial implementation was on a cluster of PDP-11/45s using 1 and 10 megabit ring networks, by 1983 the system was running on 17 VAX-11/750s using a 10 megabit Ethernet. The system was Unix compatible and provided both a single root view of the file system and a unified process space across all nodes.

The development of LOCUS was supported by an ARPA research contract, DSS-MDA-903-82-C-0189.

File system

In order to allow reliable and rapid access to the cluster wide filesystem LOCUS used replication, the data of files could be stored on more than one node and LOCUS would keep the various copies up to date. This provided particularly good access times for files that were read more often than they were written, the normal case for directories for example.

In order to ensure that all access was made to the most recent version of any file LOCUS would nominate one node as the "current synchronization site" (CSS) for a particular file system. All accesses to files a file system would need to be coordinated with the appropriate CSS.

Node dependent files

As with other SSI systems LOCUS sometimes found it necessary to break the illusion of a single system, notably to allow some files to be different on a per-node basis. For example, it was possible to build a LOCUS cluster containing both PDP-11/45 and VAX 750 machines, but instruction sets used were not identical, so two versions of each object program would be needed[note 1]

The solution was to replace the files that needed to be different on a per node basis by special hidden directories. These directories would then contain the different versions of the file. When a user accessed one of these hidden directories the system would check the user's context and open the appropriate file.

For example, if the user was running on one of the PDP-11/45's and typed the command /bin/who then the system would find that /bin/who was actually a hidden directory and run the command /bin/who/45. Another user on a VAX node who typed /bin/who would run the command /bin/who/vax.

Devices

LOCUS provided remote access to I/O devices.

Processes

LOCUS provided a single process space. Processes could be created on any node on the system. Both the Unix fork and exec calls would examine an advice list which determined on which node the process would be run. LOCUS was designed to work with heterogeneous nodes, (e.g., a mix of VAX 750s and PDP 11/45s) and could decide to execute a process on a different node if it needed a particular instruction set. As an optimization a run call was added which was equivalent to a combined fork and exec, thus avoiding the overhead of copying the process memory image to another node before overwriting it by the new image.[note 2]

Pipes

Processes could use pipes for inter node communication, including named pipes,

Partitioning

The LOCUS system was designed to be able to cope with network partitioning - one or more nodes becoming disconnected from the rest of the system. As the file system was replicated the disconnected nodes could continue to access files. When the nodes were reconnected any files modified by the disconnected nodes would be merged back into the system. For some file types (for example mailboxes) the system would perform the merge automatically, for others the user would be informed (by mail) and tools were provided to allow access to the different versions of the file.

Notes

Rather like Apple Fat binary files
run is the same operation as spawn on Windows systems.

gollark: ?

gollark: Do you know what "have prepared" means

gollark: I'm a staff member.

gollark: I am curious about what they look like. How do they compare to heav's graphic design skills?

gollark: Mass deployment of gollarious/helloboious chatbot technology. Full automation of esolang development.

References

Walker, Bruce (1983). "The LOCUS Distributed Operating System" (PDF). doi:10.1145/800217.806615.

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

[2] Rather like Apple Fat binary files

[3] run is the same operation as spawn on Windows systems.

[1] Walker, Bruce (1983). "The LOCUS Distributed Operating System" (PDF). doi:10.1145/800217.806615.