DISCONNECTED OPERATION IN THE CODA FILE SYSTEMPaper HighlightsCODAGeneral Organization (I)General Organization (II)General Organization (III)Design RationaleScalabilityPortable WorkstationsHardware ModelOther ModelsAccessibilityWhat about Consistency?ExamplePessimistic Replica ControlLeasesOptimistic Replica Control (I)Optimistic Replica Control (II)IMPLEMENTATIONClient StructureVenus States (I)Venus States (II)Prioritized Cache ManagementHoard WalkingEmulationPersistenceReintegrationSTATUS AND EVALUATIONFuture WorkSESSION SEMANTICS AND CALLBACKSUNIX sharing semanticsOpen-to-Close Semantics (I)Open-to-Close Semantics (II)Open to Close Semantics (III)Callbacks (I)Callbacks (II)Callbacks (III)Coda semanticsCONCLUSIONDISCONNECTED OPERATION IN THE CODA FILE SYSTEM J. J. KistlerM. SataynarayananCarnegie-Mellon UniversityPaper Highlights•An overview of Coda•How Coda deals with disconnected operation –File hoarding•The paper mentions but does not discuss–Callbacks (covered in my presentation)– Weakly connected operationCODA•Successor of the very successful Andrew File System (AFS)–First DFS aimed at a campus-sized user community•Key ideas include–open-to-close consistency–callbacksGeneral Organization (I)•Coda is tailored to access patterns typical of academic and research environments–Little sharing•Not intended for applications exhibiting highly concurrent file granularity data accessThis lack of sharing is typical of UNIX file systemaccess patternsGeneral Organization (II)•Clients view Coda as a single location-transparent shared Unix file system–Complements local file system•Coda namespace is mapped to individual file servers at the granularity of subtrees called volumes•Each client has a cache manager (VICE)General Organization (III)•High availability is achieved through–Server replication:•Set of replicas of a volume is VSG(Volume Storage Group) •At any time, client can access AVSG (Available Volume Storage Group)–Disconnected Operation: •When AVSG is emptyDesign Rationale•CODA major objectives were–Using off-the-shelf hardware–Preserving transparency•Other considerations included–Need for scalability–Advent of portable workstations–Hardware model being considered–Balance between availability and consistencyScalability•AFS was scalable because–Clients cache entire files on their local disks–Cache coherence is maintained by the use of callbacks, which reduce server involvement art open time•Clients do most of the work•Coda adds replicationPortable Workstations•Laptops of the late 80’s had very small disk drives–Users were manually caching the files they planned to use while being disconnected•Coda has a single mechanism to handle–Voluntary disconnections–Involuntary disconnectionsHardware Model•CODA and AFS assume that client workstations are personal computers controlled by their user/owner–Fully autonomous–Cannot be trusted•CODA allows owners of laptops to operate them in disconnected mode–Opposite of ubiquitous connectivityOther Models•Plan 9 and Amoeba–Computing is done by pool of servers–Workstations are just display units•NFS and XFS–Clients are trusted and always connected•Farsite–Untrusted clients double as servers(much more recent)Accessibility•Must handle two types of failures–Server failures:•Data servers are replicated–Communication failures and voluntary disconnections•Coda uses optimistic replication and file hoardingWhat about Consistency?•Pessimistic replication control protocols guarantee the consistency of replicated in the presence of any non-Byzantine failures–Typically require a quorum of replicas to allow access to the replicated data–Would not support disconnected modeExample•Majority consensus voting:–Every update must involve a majority of replicas–Every majority contains at least one replica that was involved in the previous update 2 3 3Pessimistic Replica Control•Would require client to acquire exclusive (RW) or shared (R) control of cached objects before accessing them in disconnected mode:–Acceptable solution for voluntary disconnections–Does not work for involuntary disconnections•What if the laptop remains disconnected for a long time?Leases•We could grant exclusive/shared control of the cached objects for a limited amount of time•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•Would only work for very short disconnection periodsOptimistic Replica Control (I)•Optimistic replica control allows access in every disconnected mode–Tolerates temporary inconsistencies–Promises to detect them later–Provides much higher data availabilityOptimistic Replica Control (II)•Defines an accessible universe: set of replicas that the user can access–Accessible universe varies over time•At any time, user–Will read from the latest replica(s) in his accessible universe–Will update all replicas in his accessible universe–IMPLEMENTATION•Client structure•Venus states•Hoarding•Prioritized cache management•Hoard walk•Persistence•ReintegrationClient StructureSystem call interfaceVnode interfaceCoda MiniCache(handles local accesses)ApplicationVenus(connects with Coda servers)Venus States (I)1. Hoarding:Normal operation mode2. Emulating:Disconnected operation mode3. Reintegrating:Propagates changes and detects inconsistenciesVenus States (II)HoardingEmulating RecoveringPrioritized Cache Management•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•Actual priority is function of hoard priority and recent usageHoard Walking•Must ensure that no uncached object has a higher priority than a cached object•Since priorities are function of recent usage, they vary over time•Venus reevaluates priorities every ten minutes (hoard walk)–Hoard walk can also be requested by user, say, before a voluntary disconnectionEmulation• In emulation mode:–Attempts to access files that are not in the client caches appear as failures to application–All changes are written in a persistent log,the client modification log (CML)–Venus removes from log all obsolete entries like those pertaining to files that have been deletedPersistence•Venus