1 / 21

Disconnected Operation in the Coda File System

Disconnected Operation in the Coda File System. 姓名：吳佳憲 學號： 491516262. Outline. Motivation An Example Disconnected Operatio n Design Rationale Prioritized algorithm. Motivation. Disconnected Operation. Continue critical work when that repository is inaccessible. Key idea: caching data.

kamuzu
Download Presentation

Disconnected Operation in the Coda File System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Disconnected Operation in the Coda File System 姓名：吳佳憲 學號：491516262

  2. Outline • Motivation • An Example • Disconnected Operation • Design Rationale • Prioritized algorithm

  3. Motivation

  4. Disconnected Operation • Continue critical work when that repository is inaccessible. • Key idea: caching data. • Performance • Availability • Server Replication

  5. An Example

  6. An Example

  7. An Example

  8. An Example

  9. An Example

  10. An Example

  11. Design Rationale • Scalability • Callback cache coherence (inherit from AFS) • Whole file caching • Fat clients. (security, integrity) • Avoid system-wide rapid change • Portable workstations • User’s assistance in cache management

  12. Design Rationale -Replication • Server replication (why?) + Persistent, Secure physically - Expensive • Client replication - Low quality relatively +Cheap

  13. Design Rationale –Replica Control • Pessimistic • Disable all partitioned writes - Require a client to acquire control of a cached object prior to disconnection • Optimistic • Assuming no others touching the file • sophisticated: conflict detection + fact: low write-sharing in Unix + high availability: access anything in range

  14. Implementation - architecture

  15. Venus - states

  16. Hoarding • Hoard useful data for disconnection • Balance the needs of connected and disconnected operation. • Cache size is restricted • Unpredictable disconnections • Prioritized algorithm – cache manage • hoard walking – reevaluate objects

  17. Prioritized algorithm • User defined hoard priority p: how interest it is? • Recent Usage q • Object priority = f(p,q) • Kick out the one with lowest priority + Fully tunable Everything can be customized - Not tunable (?) • No idea how to customize

  18. Hoard Walking • Equilibrium – uncached obj < cached obj • Why it may be broken? Cache size is limited. • Walking: restore equilibrium • Reloading HDB (changed by others) • Reevaluate priorities in HDB and cache • Enhanced callback • Increase scalability, and availability • Decrease consistency

  19. Emulation • Act like a server • Record modified objects • Replay update activity Preparation • Log based per volume • Persistence • Meta-data  RVM • Exhaustion • Compress?

  20. Conflict Handling • Only care write/write confliction • File vs Directory • File: Halt entire reintegration process • Dir: investigate more • Manual repair

  21. Conclusion • Doda is DFS with support for disconnected operation

More Related