240 likes | 359 Views
ecs251 Spring 2011 : Operating System #4: CODA. Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.facebook.com/group.php?gid=29670204725 http://cyrus.cs.ucdavis.edu/~wu/ecs251. NFS, AFS, & GFS. Read the newest copy NFS: as long as we don’t cache…
E N D
ecs251 Spring 2011:Operating System#4: CODA Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.facebook.com/group.php?gid=29670204725 http://cyrus.cs.ucdavis.edu/~wu/ecs251 CODA
NFS, AFS, & GFS • Read the newest copy • NFS: as long as we don’t cache… • AFS: the read callback might be broken… • GFS: we can check the master… CODA
NFS, AFS, & GFS • Write to the master copy • NFS: write through • AFS: you have to have the callback … • GFS: we will update all three replicas, but what happen if a read occurs during the process we are updating the copies. (name space and file to chunks mapping) CODA
Consistency • If John update file X on server A and Mary read file X on server B…. Read-one & Write-all CODA
Read x & Write (N-x+1) read write CODA
Example: R3W4 (6+1) Initial 0 0 0 0 0 0 Alice-W2 2 0 2 2 0 Bob-W 2 3 3 3 3 0 Alice-R 2 3 3 3 3 0 Chris-W 2 1 1 1 1 0 Dan-R 2 1 1 1 1 0 Emily-W7 7 1 1 1 7 Frank-R 7 7 1 1 1 7 CODA
Pessimistic versus Optimistic • Locking the world while I am updating it… • Scaleable? • “Serializable schedule” • Assuming a close system -- “you can NOT fail at this moment as I am updating this particular transaction” -- we can use “log” to handle the issue of “atomicity” (all or nothing). CODA
Soft Update • Create X (t1) and Delete Y (t2) • T1, T2 • T2, T1 • We will enforce it when resolve the problem of circular dependency! CODA
SU & Background FSCK • Soft Update guarantees that the File System will always in a “consistent” state at all time. • Essentially, Soft Update prevents any chances of inconsistency! CODA
An Alternative Approach • “Optimistic” • The chance for certain bad things to occur is very small (depending on what you are doing). • And, it is very expensive to pessimistically prevent the probability. • “Let it happen, and we try to detect and recover from that…” CODA
The Optimistic Approach • Regular Execution with “recording” • Conflict Detection based on the “recorded” • Conflict resolution CODA
Example • Allowing “inconsistencies” • Without soft update, we have to do FSCK in the foreground (before we can use it). • I.e., we try to eliminate “inconsistencies” • But, do we really need “perfectly consistent FS” for all the applications? • Why not, take a snapshot and then do background FSCK anyway! CODA
Optimistic? • NFS • AFS • GFS CODA
Optimistic? • NFS • If the server changes the access mode in the middle of an open session from a client… • AFS • “Callback” is the check for inconsistencies. • GFS • Failure in the middle of a write/append CODA
CODA • Server Replication: • if one server goes down, I can get another. • Disconnected Operation: • if all go down, I will use my own cache. CODA
Disconnected Operation • Continue critical work when that repository is inaccessible. • Key idea: caching data. • Performance • Availability • Server Replication CODA
Sequence #, Logical TS • Monotonic increasing and finite • Sequence # wrap around problem • Self-Stabilization • Global Reset CODA