Elephant: The File System that Never Forgets

1
Elephant The File Systemthat Never Forgets

• Douglas J. Santry, Michael J. Feeley,
• Norman C. Hutchinson, Alistair C. Veitch
• Proceedings of theIEEE Workshop on Hot Topics in
  Operating Systems (HOTOS), March 1999

2
Introduction

• Motivation
• Disks are becoming cheaper and larger
• Information is valuable
• Elephant file system
• Old versions of files are automatically retained
  without need for user intervention
• Managed by file-grain retention policies by the
  user
• File delete and write are easily revocable by
  rolling back the file system

3
Related Work

• Keeping multiple versions of data
• Software version control system (RCS, SCCS)
• Cedar file system
• Problems
• Heuristic for reclamation is bad
• Versioning did not apply to directories
• AFS, Plan-9, WAFL
• Problems
• Checkpoints apply to all files equally
• Changes between checkpoints cannot be rolled back

4
Elephant
5
Cleaner Policies

• keep one
• Same as standard FS model
• Good for
• /tmp, core, object file
• keep all
• Same as recent FS with snapshot capability
• Good for
• Files for which a complete history is important

6
Cleaner Policies

• keep landmarks
• Basic idea
• To designate certain versions as landmarks and
  allow other versions to be freed as necessary
• Key issue
• How to determine which versions are landmarks?

7
Keep Landmarks Policy

• Landmark designation heuristic
• Assumption
• As versions of files get older without being
  accessed, ability of user to distinguish between
  two neighboring versions decreases

8
Keep Landmarks Policy

• Landmark designation heuristic (contd)
• Example
• In the past week
• every version of a file is designated as landmark
• For versions that are a month old
• for collection of versions generated within one
  minute, only newest version is designated as
  landmark

landmark
landmark
landmark
Past week all versions are landmarks
One month old only newests are landmarks
9
Implementation

• Prototype
• FreeBSD 2.2.7
• Uses BSDs VFS/vnode interface
• Design
• Copy-on-write
• After first write
• Its inode is duplicated (creating new version)
• When file is closed
• New inode is appended to inode log

10
Implementation

• Inode Log
• Traditional FS inode number -gt inode
• Elephant inode number -gt inode log

11
Implementation

• Cleaner
• Temperature field in inode map
• Hint for cleaner to select most reclaimable file
• In current implementation, assigned using a
  heuristic based on
• Size of the file
• Number of inodes in its inode log
• More sophisticated heuristic is being
  investigated by authors

12
Implementation

• Difference between elephant cleaner and LFS
  cleaner
• LFS cleaner two roles
• Frees obsolete blocks
• Coalesces free space
• Elephant cleaner one role
• Frees obsolete blocks
• So, elephant cleaner has significantly low
  overhead than LFS cleaner (performed without
  reading any file data blocs, only inode log need
  to be accessed)

13
Conclusions

• Problem
• Forcing user to manage disk block reclamation and
  to manage multiple version is flaw in traditional
  file system
• Elephant
• Addresses this issue by providing a system
• where data blocks are immutable
• System decides when to deallocate disk blocks