"Deciding when to forget in the Elephant file system" by Douglas
Santry, et al. discusses the design, implementation, and performance
characteristic of the Elephant file system.  The basic premise of
Elephant is that disks are getting cheaper and larger fast enough that
it is practical to save all, or at least a significant portion of, the
history of every file in a system.  Existing systems already do this
on a limited scale (e.g. VMS, AFS, NetApp's WAFL), but the authors
argue that these systems do not go far enough.  It is not possible to
control the history mechanism on a per-file basis and often snapshots
are limited in scope or number.  Rather, the Elephant designers argue,
one can use a true per-file logging mechanism with flexible policies
rather than simple periodic check-pointing.  Thus, the goals for the
Elephant file system are: (1) automate storage reclamation as much as
possible while providing mechanisms for user-specified "cleaning"
policies (2) provide the ability to undo recent changes to file data
and file system structure (directories) (3) maintain long-term history
of important versions of files.  One major issue that immediately
comes to mind is how to prune the long-term history of a file: if too
many versions are kept, the user is sure to become confused, negating
the benefit of versioning.  The heuristic used in Elephant is based
upon the observation that modifications to a file tend to come in
short sequences of frequent writes.  A "landmark" can then be chosen
as the file at the time of the last of these writes.  Two problems
arise with this heuristic: (1) what should the time scale be? and (2)
how should one handle mutual consistency among a set of files?
Elephant handles the second of these problems by allowing the user to
specify groups of files (individual files or entire subtrees).  The
former problem is addressed by a cleaner process that periodically
runs in the background and, possibly with the help of an untrusted
user-level process, decides which versions of older files to remove.

The scope of the paper was impressive; one could easily imagine
splitting the paper into two pieces -- motivation and subsequent user
experience on the one hand and implementation on the other.  Not only
does it adequately motivate the need for versioning in the file
system, it discusses the semantic issues surrounding the user
interface (I would argue that the success or failure of such a system
ultimately depends upon the UI -- after all, much of the motivation
was the difficulty of tracking versions manually).  Moreover, it
provides a detailed description of the implementation, good
performance measurements, and results of initial user experience.  My
one major objection to the system as described is its complexity.  I
would have liked further evidence of the need and utility for such
fine grained policy control over versioning.