We have implemented our prototype by extending the Coda File System [3]. Although our experience is based on Coda, the general principles should also be applicable to other mobile file systems. We briefly describe Coda in this section; more information is available in the literature [3,8,7,14,13].
The Coda model is that there are many clients and a few servers. On each client, a cache manager, called Venus, carefully manages and persistently stores cached file-system objects. To support mobile computing, Coda clients can be used in disconnected and weakly connected mode, where Venus emulates the servers and allows file-system operations on cached objects. Updates are applied immediately to locally cached objects, and are also logged in a client-modify log (CML). The logging mechanism allows propagation of updates to servers to be deferred until a convenient time, such as when network connectivity is restored. Venus propagates these updates with a mechanism called trickle reintegration [14,13]. When propagation is attempted, a prefix of the log is shipped to the server in temporal order, the size of the prefix being determined by available bandwidth.
The effect of each mutating file-system operation is represented as a record in the CML. For example, a chmod operation is logged as a CHMOD record, a mkdir operation is logged as a MKDIR record. Furthermore, if there have been some intervening write operations made to an open'ed file, a subsequent close operation will be logged as a STORE record.
Records of the type STORE are special, because the associated data include the contents of the files. Therefore, these records are much bigger than records of other types. STORE records can be as large as several kilobytes or even megabytes, whereas other records are typically smaller than a few hundred bytes. Although the contents of a file logically constitute a part of the CML, they are physically stored in a separate container file in the client's local file system.
Although trickle reintegration has been shown to be effective in decoupling the foreground file-system activities from the slow propagations of updates, it still suffers from an important limitation: updated files are propagated in their entirety. In other words, although the users perceive a fast response time from the file system, the actual propagations of the updates are very slow, and they generate heavy network traffic. On a weak network, we need a more efficient scheme for shipping updates.