deciding when to forget in the elephant file system douglas s santry et al n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Deciding When to Forget in the Elephant File System Douglas S. Santry et. al PowerPoint Presentation
Download Presentation
Deciding When to Forget in the Elephant File System Douglas S. Santry et. al

Loading in 2 Seconds...

play fullscreen
1 / 13

Deciding When to Forget in the Elephant File System Douglas S. Santry et. al - PowerPoint PPT Presentation


  • 173 Views
  • Uploaded on

Deciding When to Forget in the Elephant File System Douglas S. Santry et. al. Presented by Kristen Carlson Accardi. Agenda. Motivation for Elephant FS Previous Works Design Principles Implementation Details Performance Summary. Motivation for Elephant File System.

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 'Deciding When to Forget in the Elephant File System Douglas S. Santry et. al' - deirdre-lane


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
deciding when to forget in the elephant file system douglas s santry et al

Deciding When to Forget in the Elephant File SystemDouglas S. Santry et. al

Presented by

Kristen Carlson Accardi

agenda
Agenda
  • Motivation for Elephant FS
  • Previous Works
  • Design Principles
  • Implementation Details
  • Performance
  • Summary

CS533 - Concepts of Operating Systems

motivation for elephant file system
Motivation for Elephant File System
  • Data Protection from System crashes taken care of
  • Users need protection from themselves
  • Disks are cheap, why not implement a type of revision control in the file system

CS533 - Concepts of Operating Systems

previous work
Previous Work

CS533 - Concepts of Operating Systems

efs design principles
EFS Design Principles
  • Separate Storage reclamation from file operations
    • File deletes do not release storage
    • file updates do not overwrite previous content (cow)
  • User controls file retention policy
    • cause you can't keep every user modified version
      • not every version is worth of keeping
    • you don't want to protect every file
      • read-only, cached, derived, temporary
  • two types of protection
    • undo (short term)
      • complete history is maintained
      • limited storage == limited period of time
      • can undo any change within this period of time
      • once the period of time has passed, changes are permanent
    • history of versions (long term)
      • "landmark" versions are selected by user & fs
      • intermediate changes are not saved

CS533 - Concepts of Operating Systems

how to chose landmark versions
How to chose Landmark versions
  • File system should assist user
  • it's hard for people to identify landmarks
  • fs can guess at landmarks (long delta between edits)
  • Users can still explicitly identify landmarks

CS533 - Concepts of Operating Systems

elephant file system file retention policies
Elephant File System File Retention Policies
  • Keep One
    • Standard FS behavior
    • Users directly control storage reclamation
    • Suitable for temp files, derived files, cached
  • Keep All
    • Keep every version of file
    • Not generally necessary
  • Keep Safe
    • described for "undo"
    • No long term history
  • Keep Landmarks
    • retain only landmark versions
    • users can specify
    • fs tries to guess which are landmark versions
    • use of cleaner is required to periodically tag versions as possible landmarks, and free non-landmark versions
    • User can group interdependent files for the fs

CS533 - Concepts of Operating Systems

implementation
Implementation
  • only most recent version can be modified
  • protect versioned files by copy on write
  • Duplicate the original inode
  • update new inode with new physical disk location
  • for appends, you just modify in place, but keep inode log
  • name logs are used in addition to inode logs for namespace changes

CS533 - Concepts of Operating Systems

implementation imap
Implementation - imap
  • inumber is changed to point to imap
    • inode file or inode log (meta data - type, address)
    • temperature
      • guide to the cleaner
      • value/expiration time
      • temp increases when new file version depending on how many blocks cow
    • policy
      • i.e. keep one, keep all etc.
    • policy group
      • interdependent files

CS533 - Concepts of Operating Systems

implementation inode logs
Implementation - inode logs
  • size of a disk block
  • contains an ordered list of inodes
  • reclamation/deletion information
  • directories don't have inode logs

CS533 - Concepts of Operating Systems

implementation user interface
Implementation - User Interface
  • cd file@date:hr:min
  • applications can set their own policy as well

CS533 - Concepts of Operating Systems

performance
Performance
  • Degrades with more versions
  • increases disk writes due to not being able to use buffer cache

CS533 - Concepts of Operating Systems

summary
Summary
  • Users can be protected from their own mistakes via a combination of system controlled and user defined versioning policies
  • Most files wouldn’t need versioning anyway
  • Increased overhead would be small because of small number of impacted files
  • Needs long term study to see how it scales
  • Needs more study to see how user’s react to it, and what kinds of workloads they place on it
    • i.e. will people actually use it

CS533 - Concepts of Operating Systems