1 / 16

Deciding When to Forget in the Elephant File System

Deciding When to Forget in the Elephant File System. By Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, and Jacob Or. Presented By Jon LeVitre. CS 533 Concepts of Operating Systems March 14, 2006 Slide 1. Overview. Background

rosemaryhall
Download Presentation

Deciding When to Forget in the Elephant 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. Deciding When to Forget in the Elephant File System By Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, and Jacob Or Presented By Jon LeVitre CS 533 Concepts of Operating Systems March 14, 2006 Slide 1

  2. Overview • Background • The Elephant File System • Goals and Ideas • Design • Policies • Implementation • Performance • Summary CS 533 Concepts of Operating Systems March 14, 2006 Slide 2

  3. Background • Disk space is becoming exponentially cheaper and larger • Human productivity remains constant • Data is protected from most forms of failure (except user error) • It's a good time to consider ways to make file systems protect users from themselves CS 533 Concepts of Operating Systems March 14, 2006 Slide 3

  4. Previous Work • Cedar used copy on write to automatically retain recent versions • Plan-9, AFS, and WAFL use checkpointing • Applications maintain document history • Trashcan prevents accidental deletion • Users make their own copies CS 533 Concepts of Operating Systems March 14, 2006 Slide 4

  5. Goals of EFS • Give users the ability to undo recent changes (both writes and deletes) • To save storage space, long term history only has important versions CS 533 Concepts of Operating Systems March 14, 2006 Slide 5

  6. Observations • The user's ability to recognize crucial file versions deteriorates over time • Any solution that relies solely on the user to identify landmark versions is problematic (but they need to be allowed to do it) CS 533 Concepts of Operating Systems March 14, 2006 Slide 6

  7. Types of Files • Read-only • Derived • Cached • Temporary* • User-modified* • * Only these need protection CS 533 Concepts of Operating Systems March 14, 2006 Slide 7

  8. General Design • Logical file deletion • Copy-on-write (version becomes official when file is closed) • File versions are named by combining pathname, date, and time (not unique) • Retention policy specified by file (or group of files) • File system cleaner reclaims blocks CS 533 Concepts of Operating Systems March 14, 2006 Slide 8

  9. File Retention Policies • Keep One • Keep Save • Recent changes only • Keep Landmarks • Heuristic: keep long-lived versions • Also let users specify landmarks • Keep All CS 533 Concepts of Operating Systems March 14, 2006 Slide 9

  10. File Implementation • The inumber points to an imap • Temperature is a heuristic used by the cleaner • For non-versioned files, imap points to an inode • Otherwise, imap points to an inode log CS 533 Concepts of Operating Systems March 14, 2006 Slide 10

  11. Directory Implementation • Directories map names to inumbers • Directories store versioning information explicitly • Each directory entry stores the creation time and delete time (if any) • Entries for deleted files can be moved to a history inode CS 533 Concepts of Operating Systems March 14, 2006 Slide 11

  12. Microbenchmark Results • Files with Keep One Policy was about the same as FFS (write had a bug) • Files with Keep All policy • Slightly slower open, write, and close • Much slower creation • Much faster deletion CS 533 Concepts of Operating Systems March 14, 2006 Slide 12

  13. More Microbenchmarks • Andrew file system benchmark (creates directory hierarchy, copies 70 source files totaling 200KB files, traverses directories, and opens and reads each file) • EFS was ~5% slower (19 seconds vs 18 seconds) • Much more file meta data: • FFS used 18KB for inodes • EFS used 444KB for inode logs • For larger test, EFS was twice as fast as FFS CS 533 Concepts of Operating Systems March 14, 2006 Slide 13

  14. File Profiles • Keep One: 33.6% of files, 56.3% of bytes (98.7% of bytes written) • Keep Safe: 3.9% of files, 28.5% of bytes (only 0.6% of bytes written) • Keep Landmark: 62.4% of, 15.2% of bytes (only 0.7% of bytes written) CS 533 Concepts of Operating Systems March 14, 2006 Slide 14

  15. Impact on Buffer-Cache? • Buffer-Caches reduce the number of writes to disk to improve performance • Elephant must write to disk when file is closed, even if ... • There is a write shortly after close • The file is deleted right after close. • This should be rare, so the impact should be minimal CS 533 Concepts of Operating Systems March 14, 2006 Slide 15

  16. Summary • Performance similar to FFS • Only a few files need versioning • Robustness verified using NFS shadowing • “....we believe that the extra storage and disk write overhead incurred by using a file system such as Elephant is of minimal cost compared to the convenience and time gains... made possible” • More research was needed CS 533 Concepts of Operating Systems March 14, 2006 Slide 16

More Related