Return-Path: Received: from hofmann.CS.Berkeley.EDU (hofmann.CS.Berkeley.EDU []) by orodruin.CS.Berkeley.EDU (8.7.Gamma.0/8.7.Gamma.0) with SMTP id OAA04984 for ; Sun, 21 Jul 1996 14:06:08 -0700 (PDT) Received: from (joseph.CS.Berkeley.EDU []) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with ESMTP id OAA17230 for ; Sun, 21 Jul 1996 14:06:06 -0700 Received: (from daw@localhost) by (8.6.12/8.6.9) id OAA15437 for gribble@cs; Sun, 21 Jul 1996 14:03:44 -0700 From: David Wagner Message-Id: <> Subject: no subject (file transmission) To: Date: Sun, 21 Jul 1996 14:03:43 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit


  • CODA: caching for availability, achieving disconnected operation for distributed filesystems.
  • Two techniques for achieving availability: server replication, caching across disconnected operation. Former technique is better when it is possible to use it; disconnected operation is a last resort.
  • Optimistic caching: disconnected clients get to read and write cached data, optimistically assuming there will be no conflicts. Merging must be done after reconnection.
  • Hoarding: prefetch caches, while connected, in preparation for possible (unexpected) disconnection. Depends heavily on user input.
  • Disconnected operation: emulate the server, log all file activity, be robust in face of possible client caches, accept some performance hit, possibly do cleaning if local disk becomes full with emulation logs. Cache misses extremely expensive.
  • Reconnection (`cache writeback'): replay the logs, merge conflicts manually if necessary.
  • Measurements: reconnection is fast, clients need large local disk caches (~100 MB for a day or two of disconnection-- and beware of the whole-file caching policy), conflicts predicted to be rare in their environment.
  • Very interesting possible future work: transactions support, weakly connected operation.