Disconnected Operation in the Coda File System J. J. Kistler M. Sataynarayanan Carnegie- Mellon University Presented By Mahendra Bachhav
Overview of CODA Successor of the very successful Andrew File System (AFS) Coda is tailored to access patterns typical of academic and research environments Not intended for applications exhibiting highly concurrent file granularity data access Not intended for applications exhibiting highly concurrent file granularity data access Clients view Coda as a single location-transparent shared Unix file system Coda namespace is mapped to individual file servers at the granularity of subtrees called volumes. Each client has a cache manager (VICE).
CODA design rationale CODA major objectives were o Using off-the-shelf hardware o Preserving transparency Other considerations included o Need for scalability o Advent of portable workstations o Hardware model being considered o Balance between availability and consistency
Scalability AFS was scalable because o Clients cache entire files on their local disks o Cache coherence is maintained by the use of callbacks, which reduce server involvement art open time Clients do most of the work Coda adds replication Coda avoids of system-wide rapid change No strategies requiring group consensus
Replication First class replica o AVGS copy Second class replica o Client copy Pessimistic replica control o At the mercy of a single errant client Lease o We could grant exclusive/shared control of the cached objects for a limited amount of time o Works very well in connected mode Reduces server workload Server can keep leases in volatile storage as long as their duration is shorter than boot time
Replication Would only work for very short disconnection periods Optimistic replica control o allows access in every disconnected mode Tolerates temporary inconsistencies Promises to detect them later Provides much higher data availability Defines an accessible universe: set of replicas that the user can access o Accessible universe varies over time At any time, user o Will read from the latest replica(s) in his accessible universe o Will update all replicas in his accessible universe
Implementation and terms VGS o volume storage group AVSG o Accessible VGS Venus States Hoarding: Normal operation mode Emulating: Disconnected operation mode Reintegrating: Propagates changes and detects inconsistencies
Hoarding Prioritized Cache Management o Coda maintains a per-client hoard database (HDB) specifying files to be cached on client workstation Client can modify HDB and even set up hoard profiles Hoard entry may include a hoard priority o Actual priority is function of hoard priority and recent usage Hoard Walking o Must ensure that no uncached object has a higher priority than a cached object o Since priorities are function of recent usage, they vary over time o Venus reevaluates priorities every ten minutes (hoard walk) Hoard walk can also be requested by user, say, before a voluntary disconnection
Emulation In emulation mode: o Attempts to access files that are not in the client caches appear as failures to application o All changes are written in a persistent log, the client modification log (CML) o Venus removes from log all obsolete entries like those pertaining to files that have been deleted Venus keeps its cache and related data structures in non-volatile storage All Venus metadata are updated through atomic transactions o Using a lightweight recoverable virtual memory (RVM) developed for Coda o Simplifies Venus design
Reintegration When workstation gets reconnected, Coda initiates a reintegration process o Performed one volume at a time o Venus ships replay log to all volumes o Each volume performs a log replay algorithm Found later that it required a fast link between workstation and servers Reintegration can be time-consuming o requires very large data transfers One hundred MB is enough for the cache size Conflicts are infrequent o At most 0.75% to have same file updated by two different users less than one day apart
Future Work & Conclusion Future Work o Coda added later a weak connectivity mode for portable computers linked to the CODA servers through slow links (like modems) o Allows for slow reintegration Conclusion o Puts scalability and availability before data consistency Unlike NFS o Assumes that inconsistent updates are very infrequent o Introduced disconnected operation mode and file hoarding