Replication for Mobile Computing

1
Replication for Mobile Computing
Prasun Dewan
Department of Computer Science University of
North Carolina dewan_at_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
Coda Solution Hybrid Scheme
Local Client
Network
Remote Server

• While connected, remote server

• While disconnected local client

6
Caching vs. Hoarding

• 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

7
State Transition Diagram
8
Cache replacement/filling

• 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

9
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 100d
Source Files
a /coda/src/venus 100c a /coda/include 100c
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) ltgt 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
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.