Elephant The file system that never forgets

Elephant:The File System that Never Forgets

Douglas J.Santry,Michael J.Feeley,Norman C.Hutchinson Department of Computer Science

University of British Columbia

V ancouver,Canada

dsantry,feeley,norm@cs.ubc.ca

Alistair C.V eitch Hewlett Packard Laboratories Palo Alto,California

aveitch@

Abstract

Modernfile systems associate the deletion of afile with the release of the storage associated with thatfile,andfile writes with the irrevocable change offile contents.We pro-pose that this model offile system behavior is a relic of the past,when disk storage was a scarce resource.We believe that the correct model should ensure that all user actions are revocable.Deleting afile should change only the name space andfile writes should overwrite no old data.Thefile system,not the user,should control storage allocation us-ing a combination of user specified policies and information gleaned fromfile-edit histories to determine which old ver-sions of afile to retain and for how long.

This paper presents the Elephantfile system,which pro-vides users with a new contract:Elephant will automati-cally retain all important versions of the usersfiers name previousfile versions by combining a traditional path-name with a time when the desired version of afile or direc-tory existed.Elephant manages storage at the granularity of afile or groups offiles using user-specified retention poli-cies.This approach contrasts with checkpointingfile sys-tems such as Plan-9,AFS,and WAFL,that periodically gen-erate efficient checkpoints of entirefile systems and thus re-strict retention to be guided by a single policy for allfiles within thatfile system.We also report on the Elephant pro-totype,which is implemented as a new Virtual File System in the FreeBSD kernel.

1.Introduction

Disks are becoming ever cheaper and larger.Human pro-ductivity,however,remains constant.This affords system designers an opportunity to re-examine the way we use disk stores.In particular,the previous model of user-controlled storage allocation may no longer be valid.

sion to the repository,which compresses it with respect to older versions.In essence,the goal of Elephant is to extend this idea to all clients of thefile system by moving the ver-sioning semantics into thefile system,which continues to be accessed using the traditionalfile system interface of open, close,read,write,etc,and thus freeing users from the details of version management.

While traditional Unixfile systems are single-version explicit-delete as we have described,otherfile system mod-els have been explored in both research and commercial sys-tems.The idea of versionedfiles wasfirst proposed for the Cedarfile system from Xerox PARC[10].In Cedar,files were immutable;writing to afile produced a new version of thefile andfile names included a version number(e.g.,file-name!10).A similar idea was found in the RSX,VMS[2], and TOPS-10/-20[6]operating systems from Digital.

The approach taken by these systems has two key limita-tions.First,the maximum number offile versions retained by the system was assigned as a perfile parameter;when this threshold was reached,the oldest version was deleted. However,the deletion of the oldest version is a poor heuris-tic for deciding whichfiles are valuable.Interesting versions offiles may be discarded while undesirable or less interest-ing versions still exist.Second,versioning did not apply to directories.Operations such as renaming afile,creating or destroying a directory,or,in some cases,deleting afile,were thus not revocable.

Several recentfile systems have taken a different ap-proach to versioning.In systems such as AFS[5],Plan-9[7],and W AFL[4]an efficient checkpoint of an entire file system can be created to facilitate backup or to provide users with some protection from accidental deletes and over-writes.A checkpoint is typically created and maintained in a copy-on-write fashion in parallel with the activefile sys-tem.The old version thus represents a consistent snapshot of thefile system sufficient for creating a consistent backup while thefile system remains available for modification by users.The snapshot also allows users to easily retrieve an older version of afile.

These systems differ in how frequently checkpoints are taken and in how many checkpoints are retained.In AFS and Plan-9,checkpoints are typically performed daily.In W AFL they can be performed as frequently as every few hours.Plan-9retains all checkpoints,W AFL keeps the last 32,and AFS keeps only the most recent checkpoint.

Checkpointingfile systems have two major limitations. First,checkpoints apply to allfiles equally,butfiles have different usage patterns and retention requirements.While it is not feasible to retain every version of everyfile,it may be important to keep every version of somefiles.Unfortu-nately,this dilemma cannot be solved using afile system-grain approach to checkpointing.Elephant addresses this limitationusingfile-grain retention policies that can be spec-ified by the user.Second,changes that occur between check-points cannot be rolled back.For instance,users of daily-checkpointing systems such as Plan-9or AFS are as as vul-nerable as UFS users to losing all their morning’s work in the afternoon,due to an inadvertentfile deletion or overwrite.

3.Elephant

In Elephant,all user operations are reversible.Deleting afile does not release its storage andfile writes are handled in a copy-on-write fashion,creating a new version of afile block each time it is written.Elephant’s update handling is thus similar to the Log Structured File System[4,9,11], though meta data handling and log cleaning are fundamen-tally different as discussed below.

File versions are indexed by the time they were created and versioning is extended to directories as well asfiles. When naming afile or directory,a user can optionally spec-ify a date and time as part of the name.The system resolves this name-time pair to locate the version that existed at the specified time.By rolling a directory back in time,for ex-ample,the user will see the directory exactly as it existed at the that earlier time,including anyfiles that the user subse-quently deleted.Delete thus becomes a name space manage-ment operation;every delete can be undone.

While modern systems have vast storage capacity,this storage is stillfinite.It is thus still necessary to reclaim stor-age.In Elephant,users can specify data retention policies on a per-file or per-file-group basis,in a fashion similar to access-protection information in a traditional UNIXfile sys-tem.Periodically,afile system cleaner examines thefile sys-tem and uses these policies to decide when and which disk blocks to reclaim,compress,or move to tertiary storage.A variety of policies are possible and necessary to handle the various different types offiles stored in thefile system. 3.1.Understanding What to Delete and When

Key to the design of Elephant’s version retention policies is an understanding of how users use thefile system to store various types offiles and how the increasing capacity of disk storage impacts on the decisions they make.This section summarizes our observations taken from several UNIXfile system traces[3].

Ironically,as storage becomes larger,it becomes more difficult for users to managefiles.When storage is fairly constrained,users are required to frequently assess thefiles that they are maintaining,and delete those that are no longer necessary.Typically,the ability of the user to make this assessment effectively deteriorates over time.After a few weeks or months,the user is unlikely to remember why cer-tain versions are being maintained.While there may be