Mobility

1
Mobility

• Victoria Krafft
• CS 614
• 10/25/05

2
General Idea

• People and their machines move around
• Machines want to share data
• Networks and machines fail
• Network connections not available everywhere

3
Solution
Modify network file systems so data can still be
accessed when a system is not connected to the
network.
4
Previous Work

• Grapevine developed in 1982
• Network File System (NFS) developed in 1984
• Andrew File System (AFS) developed in 1985
• Version control systems

5
Coda

• James Kistler and M. Satyanarayanan in 1992
• Lots of workstations with local disks, laptops,
  which use distributed file systems
• Expand existing cache structures to store all the
  desired data
• Want to continue work through outages

6
Environment

• Lots of untrusted Unix clients
• A few trusted servers
• High-bandwidth LAN when connected

7
Basic Design

• Shared Unix file system, with volumes mapped to
  individual file servers
• Client cache manager (Venus)
• Volume on all servers in Volume Storage Group
  (VSG)
• Client notified when cache no longer valid

8
Design Decisions

• Scalability
• Shift work to clients
• First Class vs Second Class Replication
• Servers know more than clients
• Optimistic vs Pessimistic replica control
• availability, or consistency?

9
Venus Design
10
Venus States
11
Hoarding

• Gather all useful data in cache
• User-specified critical data
• Data currently in use
• Cache equilibrium maintained by hoard walking
• Update file priority critical directories
• Re-evaluate priority of cached files
• Re-fetch outdated files

12
Emulation

• Venus acts as a pseudo-server
• Create replay log containing all updates
• Store critical data in recoverable virtual memory
  in case of crash

13
Reintegration

• Run replay algorithm on each volume
• Replay Algorithm
• Parse log and lock contents
• Log operations validated and executed
• Perform data transfers
• Commit and release locks

14
Reintegration Time
15
Cache Size
16
Conflicts?
17
Conclusions?
18
Bayous Anti-Entropy Algorithm

• Karin Petersen, Mike J. Spreitzer, Douglas B.
  Terry, Marvin M. Theimer and Alan J. Demers in
  1997
• Weakly consistent replication
• Update anywhere model

19
Environment

• Trusted servers
• WAN as well as LAN

20
Algorithm Provides

• Support for arbitrary communication topologies
• Operation on low-bandwidth networks
• Incremental progress
• Eventual consistency
• Efficient storage management
• Propagation through off-line mechanisms
• Arbitrary policy choices

21
How it works

• Storage system on each replica (server) contains
• Ordered log of writes
• Database which results from those writes
• Pairs of servers reconcile by bringing each other
  up to date
• Epidemic behavior ensures spread
• Eventually, commit and truncate write log

22
Server Reconciliation

1. When server gets write from client, write is
   logged with accept-stamp
2. For server S to update server R
3. S gets version vector from R
4. S sends all entries in its write log not in
   version vector of R.
5. Enforces property that each server which contains
   write n from server X has all writes lt n from
   server X.

23
Write Log Management

• Or How to avoid using infinite amounts of disk
  space
• Designated primary replica creates commit
  sequence number (CSN) when it writes to its
  database
• Each server manages its own log, but discards
  only stable (committed) writes

24
Revised update process

• If S has committed writes R does not know, send
  to R
• Continue with previous algorithm
• End result Write A precedes write B if A has
  smaller CSN, or if both uncommitted, accepted by
  the same server, and A accepted before B.

25
Write Log Truncation

• Server can remove committed writes from log file.
• If a server has deleted writes needed to
  reconcile with another server, the database must
  be copied.

26
Protocol Extensions

• Transportable media
• Stable write order provides eventual consistency
• Light-weight server creation/retirement

27
Server Creation/Deletion

• Server creates itself by sending a creation write
  to an existing server
• Server retires by
• Sending retirement write
• Stops accepting new writes
• Reconciles database with at least one other server

28
Design Dependencies
29
Results
30
Results
31
Conclusions?
32
Final Questions

• Peer-to-peer or server-based architecture?
• Conflict reconciliation?
• Vulnerability to failures?