Replication for Mobile Computing

1. Replication for Mobile Computing Prasun Dewan Department of Computer Science University of North Carolina dewan@unc.edu

2. Mobile Data • Address Book • Documents • Spreadsheets • Drawings • Maps • Programs Logical link Physical Location?

3. Physical Location Local Client Network Remote Server

4. Client vs. Remote • Local Client • No network cost • latency • $$$ • Availability • Disconnection is default • Involuntary • out of range • power outage • Voluntary • preserve battery • saving money • Remote Server • Larger Data Size • More Secure & Robust • Sharing possible

5. “cache” Coda Solution: Hybrid Scheme Local Client Network • While connected, remote server Remote Server • While disconnected local client

6. Classic caching Uncached data always available but with higher cost Caching for future performance Filled on demand Stale data purged Writes to cache committed immediately Hoarding Uncached data unavailable when disconnected Caching for future performance & availability partial replication Filled on demand/pre-fetched Stale data sometimes better than no data Writes to cache committed later on reconnection tracking changes conflict detection conflict resolution Caching vs. Hoarding

7. Cache data • Write through (immediate commit) Hoarding Logical Reconnection Emulation Disconnection Merging Physical Reconnection • Detect conflicts • Resolve conflicts • Provide access to cached, possibly stale data • Track changes to cached data (delayed commit) State Transition Diagram

8. Classic cache filling/replacement granularity = disk block/cache line priority = f ( recent usage) filled on access Coda cache filling/replacement granularity whole file remote disk address meaningless system-determined prefetching ancestor directories path name resolution priority = f (recent usage, user-specified) user-determined prefetching filled on access, user-request, and periodically Cache replacement/filling

9. Expanded during name-binding phase User-Determined Prefetching Per user, per workstation hoard profiles, specifying • Files to be added or deleted • Current and future (+) • children (c) • or descendents(d) • Priority Personal Files a /coda/usr/jjk d+ a /coda/usr/jjk/papers 100:d+ Source Files a /coda/src/venus 100:c+ a /coda/include 100:c+ Executables a /usr/X11/bin/xterm a /usr/X11/bin/xinit

10. Two-phase Hoard Walk • Phase 1: Reevaluate name bindings • new children matching user-specifications may have been created by other clients. • Phase 2: Recalculate priorities, evict and fetch if necessary • no un cached object higher priority than cached objects

11. Emulation • Log changes to files • mkdir d1,write f1, …. • Compress logs • (mkdir d, rmdir d, write f, write f) <=> write f • Level of write logging? • write f, contents • No need to store open and close • File updates not interleaved • write f, atOffset, buffer • More efficient • Compression advantages • some traces only 20% • others 40-100 % • variability because of hot files?

12. Merging • Problem because of concurrent conflicting modifications • Cached and server data may be modified simultaneously. • Find and resolve conflicts • Concurrent directory changes resolved automatically • Not so for files

13. Directory Merging (from LOCUS) • Operations • add(d, e) • del(d, e) • mod(d, attr, val ) • Link • Conficts • Client: add(d, e), uncached e existed on server at hoard time or server did added e to d subsequently • Client: mod(a1, v1), Server: mod(a2, v2) • Client: changed d; Server: deleted d • Or vice versa

14. write (d1/e1) link (d1/e1, d2/e2) del(d1, e1) conflict False Conflict Example touch d1/e1 mv d1/e1 d2/e2

15. File Merging • Harder problem because file is unstructured from OS point of view • Let application program that understands file structure and semantics detect and resolve conflicts • Drawing program allows concurrent additions like directory • Calendar program allows reservations at different times. • Or let user resolve conflicts • User makes different reservation • System simply calls application program

16. Issues raised by Coda • Considers strong connection and disconnection • weak connection? hoarding, emulation, or something else? • Client to server merging • client to client? • User-determined pre-fetching of files • System-determined • Application determined? • Merging depends on physical rather than logical connection. • Sometimes user wants separate version to keep changes private. • User-defined transactions!

17. Issues raised by Coda • Automatic directory merging • Synchronization guarantees a la serializability? • Inflexible resolution • May want both server and client to delete for delete to succeed (user cleaning up local hoard) • Manual (Application or end-user) file merging • Automatic (with guarantees)? • Directory and file hoarding and merging • Smaller grain than file. • Non persistent data • What if changes rejected. • Cascaded rollbacks

18. Issues raised by Coda • Client to server merging • client to client? Anti-Entropy Epidemic Algorithms • News, Lotus Notes, Bayou, TACT • Clients do pair-wise merging • Eventually consistency • Problem of write order since no single arbitrator • In host priority order

19. One- vs Two-level P2P Architectures Lotus Notes client client merging News, Grapevine, Bayou server server client

20. One- vs Two- Level C2S Architectures Sync server client Coda server server merging client

21. Issues raised by Coda • What if changes rejected. • Cascaded rollbacks • Bayou • Uncommitted writes are tentative • System keeps track of tentatively written objects. • Application can display this to user

22. Issues raised by Coda • Merging depends on physical rather than logical connection. • Sometimes user wants separate version to keep changes private. Rover • Application explicitly imports (caches) and exports (merges) objects. • Merge-aware application.

23. Issues raised by Coda User-determined pre-fetching of files • System-defined • Application-defined

24. Issues raised by Coda User-determined pre-fetching of files • System-defined • Application-defined User-determined pre-fetching of files • System-determined • Detection of file working sets. • Look at past behavior. • Trace data. • What executables forked. • What files accessed. • If current behavior looks like past behavior, cache data. • Metric for similarity. • Look at semantic distance between files.