disconnected operation in the coda file system n.
Download
Skip this Video
Download Presentation
Disconnected Operation in the Coda File System

Loading in 2 Seconds...

play fullscreen
1 / 21

Disconnected Operation in the Coda File System - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Disconnected Operation in the Coda File System' - kamuzu


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
disconnected operation in the coda file system

Disconnected Operation in the Coda File System

姓名:吳佳憲

學號:491516262

outline
Outline
  • Motivation
  • An Example
  • Disconnected Operation
  • Design Rationale
  • Prioritized algorithm
disconnected operation
Disconnected Operation
  • Continue critical work when that repository is inaccessible.
  • Key idea: caching data.
    • Performance
    • Availability
  • Server Replication
design rationale
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
design rationale replication
Design Rationale -Replication
  • Server replication (why?)

+ Persistent, Secure physically

- Expensive

  • Client replication

- Low quality relatively

+Cheap

design rationale replica control
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

hoarding
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
prioritized algorithm
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
hoard walking
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
emulation
Emulation
  • Act like a server
  • Record modified objects
  • Replay update activity Preparation
    • Log based per volume
  • Persistence
    • Meta-data  RVM
    • Exhaustion
      • Compress?
conflict handling
Conflict Handling
  • Only care write/write confliction
  • File vs Directory
    • File: Halt entire reintegration process
    • Dir: investigate more
    • Manual repair
conclusion
Conclusion
  • Doda is DFS with support for disconnected operation