Disconnected Operation in the Coda File System

Notes by Gabriel Weisz ( glw3@cornell.edu )

Goals

Strategies

Implementation Details

  • The client has a small in kernel cache and a user level process (Venus) to actually manage the cache
  • Three states for Venus (hoarding, emulation, and reintegration)
  • User editable hoard profiles to prioritize and specify files
  • Hoard walking to refresh files
  • A cache coherence protocol is used to attempt to preserve consistency for in cache data
  • A callback message is sent from servers to clients when data becomes invalid
  • All transactions are logged on the client side when disconnected, and then replayed upon reconnection
  • Users can request cache updates if they know that disconnection is immenent
  • Disconnected clients creating new files first go through a small number of preallocated permanent file ids, and later new files are given temporary file ids until reintegration
  • There's a notion of servers containing class one replicas while clients contain class 2 replicas
  • Questions

  • How do the 2 replica classes really come into play?
  • Are conflicts really as rare as they claim (it would seem that, especially on large programming projects, conflicts could easily occur when editing header files and such)
  • What happens if there's a system crash during reintegration?
  • How fast is it to fetch files during connected operation (and during reintegration)?
  • What happens if a callback message is lost?
  • Can the system be extended to work with other devices such as palmtops?