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

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

3. 3 Physical Location Network Local Client Remote Server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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