Replication for Mobile Computing Prasun Dewan Department of

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

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

Physical Location Local Client Network Remote Server 3

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

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

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

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

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

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

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 10

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

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

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(a 1, v 1), Server: mod(a 2, v 2) u Client: changed d; Server: deleted d F Or vice versa 13

False Conflict Example mv d 1/e 1 d 2/e 2 link (d 1/e 1, d 2/e 2) del(d 1, e 1) touch d 1/e 1 write (d 1/e 1) conflict 14

File Merging n n Harder problem because file is unstructured from OS point of view 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 n makes different reservation System simply calls application program 15

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 n n to client? User-determined pre-fetching of files u System-determined u Application determined? Merging depends on physical rather than logical connection. u Sometimes user wants separate version to keep changes private. u User-defined transactions! 16

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 n Automatic (with guarantees)? Directory and file hoarding and merging u Smaller grain than file. u Non persistent data n What if changes rejected. u Cascaded rollbacks 17

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 18

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

One- vs Two- Level C 2 S Architectures Sync server client server Coda merging 20

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

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. 22

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

Issues raised by Coda User-determined pre-fetching of files u System-defined u Application-defined 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. 24