Distributed Operating System

LOCUSPresented by :

Marwa MahmoudMohamed GawishTamer Rezk

Under Supervision Of :Prof.Dr. Mostafa Gadal-Haqq

Agenda

Introduction to LOCUS LOCUS main features LOCUS Distributed File System File system Operations

Read / Modification File Recovery File Merging

Introduction

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.

Main features of LOCUS

Transparent access to data Automatic replication of storage Distributed process execution Dynamic reconfiguration

Unix File System

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:

LOCUS Distributed File System Naming similar to UNIX: single directory

tree structure and file groups. It is functionally a superset of the Unix

tree structured naming system.

Distributed File System

Characteristics Uniform name space Network transparency Location transparency Location independence High availability by replication Cache consistency guaranteed

Uniform name space

The LOCUS filesystem presents a single tree structured naming hierarchy to users and applications which covers all objects in the filesystem on all machines.

Network transparency

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.

Location transparency

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

Location independence

Remote resources are accessed in the same manner as local ones.

Processes can be created locally and remotely in the same manner.

File Replication

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.

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.

File System: Operation

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

File System: Operation(cont.)

LOCUS is a procedure based operating system - processes request system service by executing system calls

File System: Operation(cont.)

Open/Read

SS CSS

File System: Operation(cont.)

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.

File System: Operation (Contd…)

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)

LOCUS Recovery

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.

PartitionsPartitions 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.

LOCUS Recovery (Contd…)

Detection of Conflicting Updates to FilesSuppose 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.

File System Merge (Contd…)

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.

File System Merge (Contd…)

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.

File System Merge (Contd…)

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.

References

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.