Det distribuerte operativsystemet LOCUS 845 ble skapt ved University of California, Los Angeles (UCLA)[1] mellom 1980 og 1983.[2][3] Den første offisielle versjon ble presentert på det åttende Symposium on Operating Systems Principles i Pacific Grove, California 14.-16. desember 1981.[5] Tidlig arbeid med prosjektet begynte allerede i slutten av 1970-årene.[2] LOCUS 845 var ikke ment for det kommersielle marked, men ble utelukkende brukt til forskning.[2] Sentrale utviklere var Gerald John Popek og Bruce J. Walker.[5] Av andre bidragsytere kan nevnes Jim Chow, D. Edwards, Charles Kline, G. Rudisin, Gregory I. Thiel, Robert English, Matthew J. Weinstein, Thomas Wingfield Page Jr. og Brian K. Livezey.[5][6][7]
I motsetning til distribuerte operativsystemer som Amoeba 809, Mach, V system og Eden, ble LOCUS 845 ikke implementert i form en mikrokjerne. Operativsystemkjernen var monolittisk, liksom i tradisjonell UNIX. LOCUS 845 var et Unix-liknende operativsystem, liksom Domain/OS, Mach og QNX.[8] Andre kategorier er prosessbaserte (Accent, Arachne, Charlotte, V system) og objektbaserte distribuerte operativsystemer (Eden, Amoeba 809).[8]
To viktige målsetninger med LOCUS 845 var nettverkstransparens og feiltoleranse.[1][4][3] LOCUS 845 var en tidlig implementasjon av single system image, hvor en dataklynge av datamaskiner tilsynelatende var en enkelt stor maskin.[3] En tredje eksplisitt målsetning var høy ytelse.[9] Dette innebar at aksesstiden til lokale systemressurser burde være sammenlignbar med aksesstiden til sentraliserte systemressurser i UNIX.[9] Dessuten burde aksesstiden til ikke-lokale systemressurser over et datanett være rimelig sammenlignbar med aksesstiden til en lokal systemressurs.[9]
Byggerne av LOCUS 845 ønsket å vise at det var mulig å bygge og implementere et nettverkstransparent, distribuert filsystem med høy ytelse som inneholdt alle de vanlige funksjoner, selv innenfor rammene av et lite datamaskinmiljø.[9] Målsetningen med prosjektet, var å bygge et distribuert operativsystem, som:[9]
støttet et nettverksvidt filsystem
tillot automatisk replikering av lagrede elementer
LOCUS 845 benyttet ikke klient-tjener modellen, som var basiskonsepter i V-system og Amoeba 809. I stedet var systemet basert på en integrert modell av distribuert databehandling, hvor hver enkelt maskins programvare var komplett, med et generelt filsystem, navnefortolkningsmekanismer, etc.[9]
Operativsystemet var kompatibelt med UNIX[1] og sørget for både en enkelt rot til filsystemet og et felles adresserom på tvers av alle nodene.[10][11] Det kan beskrives som en distribuert versjon av UNIX.[12] Absolutt all applikasjonsprogramvare var kompatibel på objektnivå, med både Berkeley Software Distribution (BSD) og UNIX System V.[12] Konverteringen fra UNIX til LOCUS 845 gikk ut på å automatisk fjerne UNIX-kjernen og tilknyttet programvare, og sette inn LOCUS 845-kjernen med dens programvare, og reformatere sekundærlager for å oppnå støtte for funksjonelle forbedringer.[12] Hver datamaskin kunne være både en klient og en tjener, med UNIX filaksess, interprosesskommunikasjon (pipe, call) og prosess-skapende (fork) primitiver som var implementert transparent over nettverket.[12]
sørge for støtte for ikke-lokalt utstyr og interprosesskommunikasjon
Enhver maskin i systemet kunne være en fullt funksjonell node. Og systemoperasjoner kunne involvere mer enn en vert.[13] LOCUS 845 kunne operere på filsystemet gjennom systemkalleneopen, create, read, write, commit, close og unlink.[13] Følgende utvidelser til UNIX ble foretatt:[13]
Den enkle trestrukturen til LOCUS 845 dekket alle objekter i filsystemet på alle maskiner. Navnene var fullstendig transparente
Filene kunne replikeres i varierende grad, og LOCUS 845 holdt alle kopiene oppdatert og arrangerte alle aksesser slik at de gjaldt den aller siste tilgjengelige versjon
LOCUS 845 sørget for standard UNIX usynkronisert filaksess og sørget i tillegg for rådgivende låsing og tvunget låsing
replikering
For å gi pålitelig og rask tilgang til filsystemet i regneklyngen benyttet LOCUS 845 replikering. Dataer fra datafiler kunne bli lagret i mer enn en node, og LOCUS 845 holdt flere forskjellige kopier oppdaterte. Dette ga spesielt god aksesstid for datafiler som ble lest oftere enn de ble skrevet, som normalt er tilfelle for eksempelvis kataloger.
For å sikre at all aksess ble gjort for den nyeste versjon av enhver datafil, nominerte LOCUS 845 en bestemt node til current synchronization site (CSS) – «nåværende synkroniseringssted» for et gitt filsystem. Alle aksesser til datafiler i et filsystem ble koordinert med den korrekte CSS.
Nodeuavhengige datafiler
LOCUS 845 fant det noen ganger nødvendig å bryte illusjonen om et enkelt system, og tillate noen datafiler å være forskjellige på en per-node basis. Deriblant var det mulig å bygge en LOCUS 845-regneklynge som bestod av både PDP-11/45 og VAX-11/750 maskiner, men instruksjonsettene var ikke identiske, slik at to versjoner av hvert objektprogram var behøvelig.
Løsningen var å erstatte datafilene som var nødvendig på en per-node basis med spesielle, skjulte kataloger. Disse katalogene ville da inneholde de forskjellige versjoner av datafilen. Når en bruker aksesserte en av disse skjulte kataloger kunne LOCUS 845 sjekke brukerens kontekst og åpne den egnede datafilen.
For eksempel, hvis en bruker kjørte på en PDP-11/45 og skrev kommandoen /bin/who, da ville operativsystemet oppdage at /bin/who egentlig var en skjult katalog og kjøre kommandoen /bin/who/45. En annen bruker som skrev kommandoen /bin/who på en VAX-11/750, ville også operere i en skjult katalog og kjøre kommandoen /bin/who/vax.
Utstyr
LOCUS 845 sørget for fjern aksess over datanettet til utstyr for inn- og utmatning.
Prosesser
LOCUS 845 sørget for et enkelt, homogent prosessrom. Prosesser kunne skapes på en hvilket som helst node i systemet. Unix-kallene fork og exec undersøkte en liste som avgjorde på hvilken node prosessen ville kjøre. LOCUS 845 var konstruert for å arbeide med heterogene noder (en blanding av VAX-11/750 og PDP-11) og kunne bestemme at prosessen skulle utføres på en annen node hvis den behøvde et spesielt instruksjonssett. Som en optimalisering ble et kjørekall tilføyd som var ekvivalent med en kombinert fork og exec, slik at man unngikk å kopiere prosessens minnebilde til en annen node før man skrev over det med det nye bilde.
Pipes
Prosesser kunne bruke pipes for kommunikasjon mellom nodene, inkludert navngitte pipes.
Partisjonering
LOCUS 845 kunne håndtere nettverkspartisjonering, hvor en eller flere noder ble koblet fra resten av systemet. Filsystemet var replikert, og frakoblede noder hadde fortsatt aksess til datafiler. Når nodene ble tilkoblet igjen ble alle datafiler som var blitt modifisert av de frakoblede noder reintegrert med resten av systemet. For noen filtyper (for eksempel e-post) ble reintegreringen utført automatisk. For andre filtyper ble brukeren informert (via e-post) om reintegreringen, og ulike verktøy ga aksess til ulike versjoner av datafilen.
Lærdommer fra LOCUS 845
En lærdom fra prosjektet, var at en nettverkstransparent distribuert filsystem med høy ytelse kunne konstrueres og implementeres selv i et lite maskinmiljø. I et slikt filsystem er det nyttig å replikere lagringen. For å oppnå høy ytelse er det nødvendig å skille mellom aksess til lokale ressurser og aksess til ikke-lokale ressurser. Den genererte koden for å oppnå dette, gir et resultat som er rettferdiggjort av økt ytelse. Det balanserende behov for protokollsynkronisering og feildeteksjon mens man vedlikeholder god ytelse, representerte derimot en betraktelig utfordring.[14]
Sheltzer, A.B.; Popek, Gerald John (1986). Internet Locus; Extending Transparency to an Internet Environment. IEEE Transactions on Software Engineering, Volume SE 12, Issue 11, IEEE Press, Piscataway, New Jersey, november 1986. s. 1067-1075. DOI 10.1109/TSE.1986.6312996.CS1-vedlikehold: Flere navn: forfatterliste (link)
Thiel, Gregory I. (1991). LOCUS operating system, a transparent system. Computer Communications, Volume 14, Issue 6, Locus Computing Corporation, 9800 La Cienega Boulevard, Inglewood, California 90301, juli–august 1991. s. 336-346. DOI 10.1016/0140-3664(91)90059-A.
Weinstein, Matthew J.; Page Jr., Thomas Wingfield; Livezey, Brian K; Popek, Gerald John (1985). Transactions and Synchronization in a Distributed Operating System. Proceedings of the Tenth ACM Symposium on Operating Systems Prinsciples, Orcas Island, Washington, USA, Operating Systems Review, Volume 19, Issue 5, 1.-4. desember 1985. s. 115-126. ISBN978-0-89791-174-0. ISBN 0-89791-174-1 DOI 10.1145/323647.323640.CS1-vedlikehold: Flere navn: forfatterliste (link)
