criteria overview - university of waterlooa78khan/cs446/additional... · 2011. 7. 27. · • an...
TRANSCRIPT
file synchronizer
data synchronizer
distributed file system
versioncontrol
Criteria Overview
Fitness for Purpose
• safety is job #1
• don’t lose or corrupt data
• even in the presence of hardware failures
• performance
• low bandwidth connections
• cross-platform
Fitness for FutureModifiability
• Not expecting much change.
• Problem is well-defined and formally specified.
• Perhaps support for new file systems.
• Non-hierarchical FS?
Reusability
• Not designed for reusability.
• Can call the binary.
• Build a data synchronizer?
Cost of Production
• An academic project
• Supporting thousands of users
• Willing to spend time on interesting things
• Written in OCaml
• strongly-typed functional language
• close to formalism
Cost of Operation
• Not a primary design consideration
• In practice requires a server
• DropBox’s competitive advantages:
• DropBox provides the server
• DropBox has a simpler UI
Main AlternativesTrace-Based
• work from a log of edits
• used by:
• distributed DBs
• middleware
• git
State-Based
• work from the current state of the data
• used by:
• unison
• dropbox
• subversion
Safety
Invariant #1
At every moment, each path in each replica has either
1. its original contents (i.e., no change at all has been made to this path), or
2. its correct final contents (i.e., the value that the user expected to be propagated from the other replica).
Invariant #2
At every moment, the information stored on disk about Unison's private state can be either
1. unchanged, or
2. updated to reflect those paths that have been successfully synchronized.
How to atomically replace a file?
How to atomically replace a file?
• Most file systems do not have an atomic replace operation.
1. Create a tmp file with the new contents
2. Delete the old file
3. Rename the tmp file to the proper name
CaveatThe above is almost true there are occasionally brief periods where it is not (and, because of shortcoming of the Posix filesystem API, cannot be). In particular, when it is copying a file onto a directory or vice versa, it must first move the original contents out of the way. If Unison gets interrupted during one of these periods, some manual cleanup may be required. In this case, a file called DANGER.README will be left in our home directory. Next run Unison will warn us about it.
Update Detection Alternatives
Trivial Detection
• Always say every file has been modified
• Requires comparing the state of every file
• Expensive if files are large and link is slow
Exact Detection
• Keep a local copy of the data at the time of last synchronization (Subversion does this)
• Doubles the disk space
• May also be computationally expensive
Modtime Check
• Works in theory but not in practice
• In *nix, renaming a file does not change its modtime
• changes the modtime of the parent dir
• directory modtime may be changed for other reasons
• renaming a file near the root will make the whole tree look dirty
INode + Modtime
• Dirty =
• inode changed or
• modtime > last synchronization time
• INodes contain file metadata: size, permissions, owner, group, etc.
• but not file names
• Ok for Posix systems, but not for Windows
Online Detection
• Listen to file system events
• What DropBox does
• Easier to implement at the user level on Windows than on *nix
• Some wrappers for Unison try to do this
Reconciliation
What does the user expect?
Synchronization (a simple example)
A synchronizer should propagate changes...
DIR
f’ g’
ba
DIR
f’ g
ba
DIR
f g’
ba
DIR
f’ g’
ba
snc / 6
Easy
Cas
e: N
on-c
onfli
ctin
g ch
ange
s
Easy
Cas
e: C
onfli
ctin
g ch
ange
s
... as long as they do not conflict:
DIR
f’ g’’
ba
DIR
f’ g’
ba
DIR
f g’’
ba
DIR
f’ g’
ba
snc / 7
A more interesting example
If a file gets renamed on one side and modified on the other, what shouldthe synchronizer do?
DIR
f g
ba
DIR
f g’
bac
g
snc / 8
rename modify
???
Three reasonable possibilities:
1. Copy old version with new name ( ); report a conflict for old name( )
DIR
f
a
DIR
f g’
bac
g
c
g
2. Modify the file in the first replica and move it in the second
DIR
f
a
DIR
f
ac
g’
c
g’
3. Do nothing (report a conflict)
snc / 9
Another unclear case
Suppose a file is created on one side and its parent directory is deletedon the other side...
DIR
d
DIR
DIR
f
d
ba
g’
DIR
f
a
What should happen?
snc / 10
Another unclear case
Suppose a file is created on one side and its parent directory is deletedon the other side...
DIR
d
DIR
DIR
f
d
ba
g’
DIR
f
a
What should happen?
snc / 10
1. Nothing; a conflict should be reported
2. The siblings ( ) should be deleted from the second replica, leavingjust the file ( ) and its parent directory ( )
3. The siblings and parent directory should all be deleted from thesecond replica; the file should be moved to a special “orphanage” andthe user alerted
snc / 11
A, B are filesystemsp is the path to be synchronizedreturns “new” file systems with synchronized contents
Specification
Conflicts
Key question: What is a conflict?
Our answer: A conflict occurs when the two replicas do not agree (atsome path), and both have been changed.
Formally, we say there is a conflict at path if
“ and are different at ”
and “ has been changed at (or below) ”
and “ has been changed at (or below) ”
snc / 17-b
Core Specification
Each run of a file synchronizer takes filesystems , , and as inputsand yields new filesystems and as outputs. A run is said to beacceptable if, for all paths :
(1) if , then
if , then
(“don’t overwrite user changes”)
(2) if , then
if , then
(“only change replicas by (completely) propagating user changes”)
(3) if there is a conflict at , then and
(“don’t change (at or below) conflicting paths”)
A synchronizer implementation is correct if all its runs are acceptable.
snc / 18
Architecture
Client FS Server FS
rpc over ssh
ServerClient
System Architecture
replicaarchive
replicaarchive
su
er I
U
updatedetector detector
update
reconciler
transportagent
snc / 29
PerformanceThe RSync Algorithm
Extensions
Synchronizing Multiple replicas
We’ve treated just the two-replica case in this specification (and in ourimplementation).
Pairwise synchronization can be used to keep 3-5 replicas in sync. Justsynchronize successive pairs in a star or ring topology.
For synchronizing more replicas, both specification and implementationcan be extended straightforwardly... iff we require that all replicasparticipate in every synchronization.
For synchronizing many replicas, we need to deal with the fact that onlya subset may participate in any given sync. Problems become significantlytrickier. (Need something like version vectors.)
snc / 23
Data Synchronization
• Should fit in the formalism
• As long as the data is hierarchical
• Just extend the notion of path to records