Disconnected Operation in the Code File System (CMU, 1991)

Jonathan Ledlie CS 736 
April 14, 2000

Coda takes the Andrew File System to the next level of distributed 
operation through incorporating mobile and disconnected operation in its design 
from the ground up.  Users specify which files are important to them by adding the 
names of the files they care about to the hoard database, which Venus keeps in sync 
with the Vice servers to which the client machine is connected.  When a node becomes 
disconnected, either voluntarily or through some communication failure, the 
client can then continue operating on its copy of the files; in this state, it is said 
to be in emulation mode.  When the connection returns, Coda reintegrates the files 
back with Venus.  Two assumptions are that the node will not be disconnected for a 
very long time and that the data does not require fine-grained ACID semantics: Coda 
“is specifically not intended for applications that exhibit highly concurrent, 
fine granularity data access.”  The main problem with this reintegration is that if 
several sources modify the same parts of the same file then automatic 
reintegration may be impossible and human reintegration may be too complex.  When 
describing this same situation in his “Dangers of Replication” paper, Gray called 
this unfortunate state “system delusion.”  To help with reintegration, Coda 
maintains a database-like log called the replay log.  I thought two other aspects of 
this paper were particularly interesting.  First, they incorporated in their 
design the possibility that Vice can become partitioned and still function.  I 
think the likelihood of this is low enough to merit not enforcing the data policies 
need to make it work (Figure 1: c, d, and e).  Second, their idea of a recoverable 
virtual memory where the “actual contents of cached files are not in RVM, but are 
stored as local Unix files” may have useful applications beyond Coda.