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

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

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 CS533 - Concepts of Operating Systems

5. 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

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 • 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

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 • 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

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 file@date:hr:min • 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 • i.e. will people actually use it CS533 - Concepts of Operating Systems