Work
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, wher…
Read and enrich the people, organizations and context referenced in case files.
Explore the cases that include this wiki entry.
No case files include this entry yet.
Investigate this subjectLOCUS 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.
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.
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.
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.
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.
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
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.
LOCUS provided remote access to I/O devices.
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.
Processes could use pipes for inter node communication, including named pipes,
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.
Source: LOCUS (CC BY-SA)
We label verified structured information, user opinions, and AI-discovered relationships separately.
Be the first to comment.
