Locus Distributed Operating System
Download as PPTX, PDF0 likes3,710 views
The document describes LOCUS, a distributed operating system developed at UCLA between 1980-1983. LOCUS provides network transparency and high availability through automatic replication of storage across nodes. It uses a single hierarchical directory structure and allows transparent access to files regardless of physical location. The system aims to guarantee cache consistency and allows for distributed process execution and dynamic reconfiguration.
Locus Distributed Operating System
- 1. Presented by: Under Supervision Of: Prof.Dr. Mostafa Gadal-Haqq
- 2. Introduction to LOCUS LOCUS main features LOCUS Distributed File System File system Operations Read / Modification File Recovery File Merging
- 3. LOCUS is a distributed operating system that provides a very degree of network transparency while at the same time supporting high performance and automatic replication of storage. Is compatible with Unix OS. Was developed at UCLA (University of California, Los Angeles) between 1980 and 1983 with supporting by DARPA.
- 4. Transparent access to data Automatic replication of storage Distributed process execution Dynamic reconfiguration
- 5. In Unix, files are organized into a tree structure with a root named by the character ’/’. The first few levels of the tree look like this:
- 6. Naming similar to UNIX: single directory tree structure and file groups. It is functionally a superset of the Unix tree structured naming system.
- 7. Characteristics Uniform name space Network transparency Location transparency Location independence High availability by replication Cache consistency guaranteed
- 8. The LOCUS filesystem presents a single tree structured naming hierarchy to users and applications which covers all objects in the filesystem on all machines.
- 9. LOCUS makes the network of machines appears to users and programs as a single computer. Files can be moved dynamically with no effect on naming.
- 10. LOCUS names are fully transparent; it is not possible from the name of a resources to discern its location in the network. Transparent Naming: pathname works anywhere Name resolves to <filegroup number, inode number> Search for the pathname iteratively starting from working directory or root Finds a <filegroup, inode> at the end of search
- 11. Remote resources are accessed in the same manner as local ones. Processes can be created locally and remotely in the same manner.
- 12. The data of files could be stored on more than one node and LOCUS would keep the various copies up to date. Motivation for Replication Availability ▪ Multiple copies of data resources provide the opportunity for substantially increased availability. Performance ▪ If users of the file exist on different machines, and copies are available near those machines, then read access can be substantially faster compared to the necessity to have one of the users always make remote accesses.
- 13. 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.
- 14. There are three logical functions in a file access : Using Site (US) The request to open a file and to which pages of the file are to be supplied. Storage Site (SS) Is the site at which a copy of the requested file is stored, and which has been selected to supply pages of that file to the using site. Current Synchronization Site (CSS) Which enforces a global access synchronization policy for the file's filegroup and selects SSs for each open request. A given physical site can be the CSS for any number of filegroups but there is only one CSS for any given filegroup in any set of communicating sites
- 15. LOCUS is a procedure based operating system - processes request system service by executing system calls
- 16. Open/Read SS CSS
- 17. First, information on inode decide whether US can directly read the file locally, usually after the first open Otherwise, the US request CSS, which is determined by the logical mount table, if the file in CSS, return the information from itself, if not, CSS set up an incore inode structure, which store the state information for synchronization and store the sites who store the file, as well as a version vector, check which SS store the last version of file. After decision, the incore inode(already revised) is sent to the US, which means the US can directly contact with SS by using the logical page number and a guess: two buffer cache are used. Both at SS and across the network.
- 18. Creation Storage locations for new file determined at create time. Attempts to use same storage sites as parent directory/local site Remote sites – inode allocated by physical container Modification Modifications are written to new pages, followed by atomic commit, remote update Commit & Abort ▪ One copy of file is updated and committed ▪ Updated file propagation - “Pulling” by other SS Machine Dependent File Different Versions of the same file (Process Context based)
- 19. The basic approach in LOCUS is to maintain, within a single partition, strict synchronization among copies of a file so that all uses of that file see the most recent version, even if concurrent activity is taking place on different machines. Partitions Partitions clearly are the primary source of difficulty in a replicated environment. For example, while site B is down, work is done on site A. Site A goes down before B comes up. When site A comes back up, an effective partition merge must be done.
- 20. Detection of Conflicting Updates to Files Suppose file f was replicated at sites S1 and S2 . Initially assume each copy was identical but after some period sites S1 and S2 partitioned. If f is modified at S1 producing f1 then when S1 and S2 merge the two copies of f will be inconsistent. Are they then in conflict? No. The copy at S1 (fl) should propagate to S2 and that will produce a consistent state. The copies of the object would be in conflict if during the partition not only was S1's copy modified to produce fl but S2's copy was modified to produce f2. At merge a conflict should be detected. As already pointed out the system may be able to resolve the conflict.
- 21. The LOCUS file system is a network wide, tree structured directory system, with leaves being data files whose internal structure is unknown to the LOCUS system nucleus. All files, including directories, have a type associated with them. The type information is used by recovery software to take appropriate action.
- 22. The LOCUS recovery and merge philosophy is hierarchically organized. The basic system is responsible for detecting all conflicts. For those data types that it manages, including internal system data as well as file system directories, automatic merge is done by the system. If the system is not responsible for a given file type, it reflects the problem up to a higher level; to a recovery/merge manager if one exists for the given file type.
- 23. Difficulties of Merging : a) operations (remove, rename and link) may be done to a file in a partition which does not store the file. b) a file which was deleted in one partition while it was modified in another, wants to be saved. c) a directory may have to be resolved without either partition storing particular files.
- 24. G. Popek, B. Walker, J. Chow, D. Edwards, C. Kline, G. Rudisin, G. Thiel, LOCUS: A Network Transparent, High Reliability Distributed System, University of California, Los Angeles. Bruce Walker, Gerald Popek, Robert English, Charles Kline and Greg Thiel, The LOCUS Distributed Operating System, University of California, ACM, Los Angeles, 1983.