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. Bayou’s 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: 1. Ordered log of writes 2. 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: 1. S gets version vector from R 2. S sends all entries in its write log not in version vector of R. 3. Enforces property that each server which contains write n from server X has all writes < 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 1. If S has committed writes R does not know, send to R 2. 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

31. Conclusions?

32. Final Questions Peer-to-peer or server-based architecture? Conflict reconciliation? Vulnerability to failures?