Deciding When to Forget in the Elephant File System Douglas S. Santry et. al Presented by Kristen Carlson Accardi

CS533 - Concepts of Operating Systems 2 Agenda  Motivation for Elephant FS  Previous Works  Design Principles  Implementation Details  Performance  Summary

CS533 - Concepts of Operating Systems 3 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 4 Previous Work  Automatically copy on write file  Trashcan Not enough versions could be retained  Backups  Checkpoints Intermediate versions are lost

CS533 - Concepts of Operating Systems 5 EFS Design Principles  Separate Storage reclamation from file operations o File deletes do not release storage o file updates do not overwrite previous content (cow)  User controls file retention policy o cause you can't keep every user modified version not every version is worth of keeping o you don't want to protect every file read-only, cached, derived, temporary  two types of protection o 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 o history of versions (long term) "landmark" versions are selected by user & fs intermediate changes are not saved

CS533 - Concepts of Operating Systems 6 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 7 Elephant File System File Retention Policies  Keep One o Standard FS behavior o Users directly control storage reclamation o Suitable for temp files, derived files, cached  Keep All o Keep every version of file o Not generally necessary  Keep Safe o described for "undo" o No long term history  Keep Landmarks o retain only landmark versions o users can specify o fs tries to guess which are landmark versions o use of cleaner is required to periodically tag versions as possible landmarks, and free non-landmark versions o User can group interdependent files for the fs

CS533 - Concepts of Operating Systems 8 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 9 Implementation - imap  inumber is changed to point to imap o inode file or inode log (meta data - type, address) o temperature guide to the cleaner value/expiration time temp increases when new file version depending on how many blocks cow o policy i.e. keep one, keep all etc. o policy group interdependent files

CS533 - Concepts of Operating Systems 10 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 11 Implementation - User Interface  cd  applications can set their own policy as well

CS533 - Concepts of Operating Systems 12 Performance  Degrades with more versions  increases disk writes due to not being able to use buffer cache

CS533 - Concepts of Operating Systems 13 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 o i.e. will people actually use it