The LOCUS Distributed Operating System

Walker83

Key characteristics:

• network transparency – make a distributed group of machines appear as one
• high reliablility – file replication (OS fault-tolerant to network partitions)+ nested transactions
• UNIX compatible

File system:

• name transparency – entire directory tree is same for all nodes, and can’t tell where a file/directory is located based on its name
• file interface transparency – system calls to operate on local files and directories are exactly the same that can be used to operate on remote files and directories

Advantages of distributed replicated filesystem:

• Increased availability – can still get a file even if the “regular” server is down
• Increased performance – can get a file from the “closest” server
• Increased performance – directories are naturally well suited for replication; root directory is most frequently accessed, and should be replicated to improve performance; directories lower in the tree should not be replicated as much as they will not be accessed as frequently.

Three types of sites (can be co-located on one machine):

• US – Use Site (client)
• SS – Storage Site (has a copy of file being accessed; handles shadow paging, and informs other SSs storing the same file when an update is made; the other SSs then pull the updated file using standard I/O calls)
• CSS – Current Synchronization Site (global synchronization point for file being accessed; has knowledge of all the SS’s for a particular file)

Files have version vectors. CSS knows the most recent version vector for a given file.

File access is done logical pages at a time, similar to NFS. (or does NFS do blocks?)

Sys calls supported: open, create, read, write, commit, close, unlink. (abort?)

LOCUS uses shadow paging instead of logging because 1) most file modifications tend to overwrite entire files, and 2) shadowing provides higher performance (requires no I/O on abort) and is easier to implement.

Since hardware/processors in LOCUS are heterogeneous, all binaries are stored in hidden directories containing binaries for all different architectures, and the correct binary is pulled out based upon the client doing the access. (This differs from the Plan 9 approach, where each client has their own namespace, and the binaries are aliased to the correct binaries for that client’s architecture.)

Recovery in LOCUS

Do synchronization within a partition; work independently across partitions.

When the system merges, use automatic reconciliation for file types that the system or

some registered application understands; email users to reconcile other types of files.

In a complex distributed system, some type of partition will always occur at some point (due to hardware failures, software failures, etc.)

Why allow people to do work in the face of partition?

1) If you don’t, availability goes down as replicaiton increases.

2) OS must be able to make updates in the face of partition, why not make mechanism used to handle this available to users?

3) Conflicts are relatively rare anyway.

[Compare this to rationale in Coda.]

Primary copy, Majority Consensus, and Weighted Voting all allow work in only one partition. Need to come up with new protocol....

• In the case that two different files are assigned the same name in different partitions, the system renames them slightly differently and emails the owners.
• If an entry (file or dir) is in one directory and not the other, propagate the entry.
• If a file is deleted in one directory, and not modified in the other, then delete, else report to owner.

Since mailboxes are used to report conflicts, mailboxes must be reliably merge-able across partitions. However, since the only operations on mailboxes are adds/deletes of entire messages, this is easy.

Dynamic Reconfiguration

Dynamic reconfiguration should be transparent to users (they should not be able to tell that a reconfiguration takes place). If a process is accessing a file, and the version it is accessing becomes inaccessible, the system will try to subsititue a replicated version without letting the application know when partition takes place.