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.