The LOCUS Distributed Operating System

1
The LOCUS Distributed Operating System

• Bruce Walker, Gerald Popek, Robert English,
• Charles Kline and Greg Thiel
• University of California at Los Angeles
• 1983
• Presented By
• Henry Wong
• Karthik Chandrasekar

2
LOCUS Distributed System

• Transparency
• Looks like one system, though each node runs a
  copy of the OS
• Procedure-based system
• File system with name transparency and
  replication
• Remote process creation

3
Overview

• Distributed File System
• Transparent access through a network
• Replication
• Recovery from conflicts
• Dynamic Reconfiguration
• Remote Processes

4
Distributed File System

• Naming similar to UNIX single directory tree
• Transparent Naming pathname works anywhere
• Name resolves to ltfilegroup number, inodegt
• Replication
• Performance
• Availability
• Replication of Environment Set up files
• Directory entries stored nearby
• Physical containers store subset of filegroups
  files
• Version vector for conflict detection

5
Name resolution

• Search for the pathname iteratively starting from
  working directory or root
• Finds a ltfilegroup, inodegt at the end of search
• Possible optimization Partial Path
• Instead of iterating through a tree which is
  remotely located

6
File System Operation

• Access
• Using Site (US)
• Storage Site (SS)
• Current Synchronization Site (CSS)

ltfilegroup number, inodegt
7
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)

8
Recovery

• Partitioning will occur
• Strict Synchronization in a partition
• Merging
• Directories and mailboxes are easy
• Issue File is both deleted and updated
• Solution Propagate changes/Delete, whichever is
  later
• Name conflict Rename and email
• Automatic - CSS
• Else, pass to filetype-specific recovery program
• Else, Email owner

9
Dynamic Reconfiguration

• Principles for Reconfiguration
• Delays (internal table reconstruction) should be
  negligible
• Same version availability even upon failure -
  Consistency
• Clean up when failure detected
• Close files and sessions issue error return
  values
• Partition Find connected component
• Synchronize site tables
• Polls all suspected-good machines then broadcast
  result
• Merge Forms large partitions - Centralized
• Polls all sites asynchronously, merges partitions
  if found.
• Finds new CSS for all filegroups and global
  tables.
• Protocol Synchronization
• Passive site periodically checks active site
• Passive site can restart protocol

10
Remote Processes

• Supports remote fork and exec
• Copies entire process memory to destination
  machine can be slow
• run system call performs the equivalent to local
  fork and remote exec
• Shared data protected using token passing (e.g.
  file descriptors, handle)
• Child ?? Parent notified upon failures

11
Conclusion

• Transparent Distributed System Behavior with high
  performance is feasible
• Performance Transparency
• Except remote fork/exec
• Not much experience with replicated storage
• Protocol for membership to a partition with high
  performance works