Computer Science Department

Technical Report
NWU-CS-04-30
January 20, 2004

Wayback: A User-level Versioning File System For Linux

Brian Cornell Peter Dinda Fabián Bustamante

Abstract
In a typical file system, only the current version of a file (or directory) is available. In
Wayback, a user can also access any previous version, all the way back to the file’s
creation time. Versioning is done automatically at the write level: each write to the file
creates a new version. Wayback implements versioning using an undo log structure,
exploiting the massive space available on modern disks to provide its very useful
functionality. Wayback is a user-level file system built on the FUSE framework that
relies on an underlying file system for access to the disk. In addition to simplifying
Wayback, this also allows it to extend any existing file system with versioning: after
being mounted, the file system can be mounted a second time with versioning. We
describe the implementation of Wayback, and evaluate its performance using several
benchmarks.
Keywords: file systems, version control
 Wayback: A User-level Versioning File System for Linux
Brian Cornell Peter Dinda Fabian Bustamante
Computer Science Department, Northwestern University
{techie,pdinda,fabianb}@northwestern.edu

Abstract

In a typical file system, only the current version of a file (or directory) is available. In Wayback, a user can also ac-
cess any previous version, all the way back to the file’s creation time. Versioning is done automatically at the write
level: each write to the file creates a new version. Wayback implements versioning using an undo log structure, ex-
ploiting the massive space available on modern disks to provide its very useful functionality. Wayback is a user-lev-
el file system built on the FUSE framework that relies on an underlying file system for access to the disk. In addition
to simplifying Wayback, this also allows it to extend any existing file system with versioning: after being mounted,
the file system can be mounted a second time with versioning. We describe the implementation of Wayback, and
evaluate its performance using several benchmarks.

1 Introduction crosoft Word) provide their own internal versioned file

format. Here the versioning is usually done automati-
A user of a modern operating system such as Linux ex- cally at the granularity of a whole editing session.
periences a very simple file system model. In particu-
lar, the file system only provides access to the current We believe that a better way to help the user revert to
versions of his or her files and directories. The trouble earlier versions of his file is to automatically provide
with this model is that the user’s progress in his work is versioning in the file system itself, and to provide it at a
not monotonic – the user makes mistakes such as dis- fine granularity. To this end, we have developed the
carding important text in a document, damaging careful- Wayback versioning file system for Linux. With no us-
ly tuned source code through misunderstanding, or even er interaction, Wayback records each write made to
accidentally deleting files and directories. Beyond mis- each file or directory into a permanent undo log [UN-
takes, it is often helpful, especially in writing code or DO]. The undo log can then be unwound in reverse or-
papers to look at the history of changes to a file. If the der (prompted by a user-level tool) to rollback to or ex-
user could “go back in time” (using the “wayback ma- tract any previous version of a file. Wayback is imple-
chine”1 for which our file system is named, for mented as a user-level file system using the FUSE ker-
example), he would be in a better position to recover nel module [FUSE]. It operates on top of an existing,
from such mistakes or understand how a file got to its non-versioned file system, adding versioning functional-
current state. ity.

Of course, version control systems such as RCS [RCS] Versioning file systems have been around for quite
and CVS [CVS] provide such functionality. However, some time. The VMS operating system from DEC in-
the user must first become familiar with these systems troduced versioning to a broad range of users. The
and explicitly manage his files with them. In particular, VMS file system created a new version of a file on each
the user must tell these systems when a new version of close [VMS]. The Elephant versioning file system was
his files is ready by explicitly committing them. Hence, among the first to recognize that versioning was a excel-
the user determines the granularity of versions, and, lent way to exploit the massive (and exponentially
since he must explicitly make them, they tend to be growing) disk sizes that are available today [Elephant].
large. Some tools such as EMACS include drivers to There has since been an explosion of interest in version-
automate this process. Some applications (e.g. Mi- ing file systems. Wayback does versioning at the level
of writes and hence is a comprehensive versioning file
1
The “wayback machine” was Dr. Peabody’s time ma- system [CVFS]. Its ability to run on top of an existing
chine in the classic cartoon series “Peabody’s Improba- file system is similar to the concept of a stackable file
ble History” by Ted Key.

1
system [VersionFS]. As far as we are aware, Wayback being natural to revert or extract a file or directory as it
will be the first public release (under the GPL) of a ver- existed at a particular point in time.
sioning file system for Linux. We will make a copy
available to any reviewer who contacts us.
3 Implementation
2 User's View Of The Wayback FS Wayback FS is implemented as a user-space server that
is called by the FUSE kernel module. In essence,
Wayback FS requires a recent 2.4 Linux kernel, gcc FUSE traps system calls and upcalls to the Wayback
2.95.2 or higher, and Perl 5. We have used kernel ver- server. The server writes an entry into the undo log for
sions as early as 2.4.7-10 (shipped with Red Hat 7.2). the file or directory that reflects how to revert the ef-
The FUSE user-level file system module is used (ver- fects of the call, and then executes the call on the under-
sions 0.95 and up). The current Wayback distribution is lying file system.
shipped along with the FUSE source. Compilation in-
volves the typical GNU automake sequence. The out-
put includes: 3.1 Log Structure For Files
• fuse.o: FUSE kernel module Each file for which versioning information exists has a
• versionfs: Wayback FS user-space server shadow undo log file, named by default “<filename>.
• vutils.pl: command-line utility for manipulating versionfs! version”. Each log record consists of:
files.
• A time stamp,
Four symbolic links to vutils.pl are also created to ex- • The offset at which data is being overwritten or
pose its basic functions: truncated,
• The size of the data that is being lost,
• Whether the file size is increasing due to writing
• vstat: Describe a versioned file.
off the end of the file, and
• vrevert: Revert a versioned file to an earlier ver-
• The data being lost, if any.
sion.
• vextract: Extract a specific version of a file.
• vrm: Permanently remove a file.
3.2 Logging File Operations
To mount a Wayback file system, the underlying file
system is first mounted in the normal manner, then it is Wayback traps calls to write() and truncate() for files.
remounted by starting a Wayback server: Every time write() is called on a file, versionfs reads the
portion of the file that the write call will overwrite and
$ versionfs path-in-underlying-fs mount-path records it in the log. The offset recorded is the offset in
the file at which data is being written, the size is either
After this, the user can access his files through mount- the number of bytes to the end of the file or the number
path. Any change made will be logged and is reversible of bytes being written (whichever is smaller), and the
using vrevert. Old versions can also be copied out us- data is the size bytes at offset that are currently in the
ing vextract. Even “rm” is logged and can be undone. file.
To permanently remove a file, vrm is used. Notice that
it is possible to mount the directory hierarchy under any When truncate() is called on a file, the offset recorded is
path as a new, versioned, file system. It is also possible the length to which the file is truncated, size is the num-
to continue to manipulate files in the original path, but ber of bytes in the file after that point, and data is that
those changes will not be logged and are not revertible. data that is being discarded due to truncation.

Versions are tagged in two ways: by change number

(starting with one being the most recent change) and by
time stamp. The user most often uses the time stamp, it

2
3.3 Log Structure For Directories
4.1 Kernel Versus User-level
Every directory has a shadow undo log that we call the
directory catalog. The directory catalog logs when any The first major decision we had to make was whether
entry in the directory is created, removed, renamed, or this file system should be implemented in the kernel as
has its attributes change. The directory catalog has the its own file system, or using a user-level module. The
default name “<directory>/. versionfs! version”. Each trade-offs are in speed, ease of implementation, and fea-
log record consists of: tures. A kernel module would undoubtedly be much
faster because the user-level overhead would be avoid-
• A time stamp,
ed. However, it could limit compatibility to certain ker-
• The operation being performed,
nel versions, and it would preclude adding versioning to
• The size of the data recorded for this operation,
existing file systems. It would also be much harder to
and
• The data needed to undo the operation. The in- implement a kernel module.
terpretation of the data depends on the operation.
The main factor in our decision to make a user-level file
system had to do with the features we could easily im-
3.4 Logging Directory Operations plement. We considered writing Wayback as a kernel-
level extension to ext3. This would probably have been
When mknod(), mkdir(), or creat() is called, a link is faster, but it would have been limited to ext3 file sys-
created, or open() is called with the O_CREAT flag, the tems on normal block devices. Implementing Wayback
directory catalog is updated with the create or mkdir op- as a user-level file system would make it slower, but
eration number and data consisting of the filename that would let us remount any file system with versioning.
is being created.

When unlink() is called on a regular file, the file is first 4.2 Choice of Undo Logging
truncated to zero length to preserve the contents of the
file before deletion. Next, the directory catalog is updat- Wayback logs changes as undo records. We recover
ed with data consisting of the attributes of the file previous versions by applying these records in reverse
(mode, owner, and times) and the filename that is being order until the appropriate version is reached. This is
deleted. For links, the destination is also recorded. straightforward, but it has a downside: while reverting
to newer versions is very fast, reverting to very old ver-
Calls to rmdir() in Wayback actually translate to calls to sions can take some time. One alternative is a redo log,
rename(). Directories are never deleted because their
in which modifications themselves are written as log
contents would be lost. Instead an identifier such as “.
records. Recovering an old version means applying the
versionfs! deleted” is added to the directory name. Sub-
sequently, and for user-initiated rename() calls, the di- records in forward order until the appropriate version is
rectory catalog is updated with data consisting of the reached. This has the advantage of allowing very old
old name of the file or directory, and the new name of versions to be recovered very quickly, but newer ver-
the file or directory. sions are slow. A third possibility is an undo/redo log,
which contains both undo and redo records, allowing us
When chmod(), chown(), or utime() is called, the direc- to move backward and forward easily. Each logging
tory catalog is updated with the with data consisting of technique can be combined with periodic checkpoint-
the attributes of the file and the filename for which at- ing, providing snapshots of the whole file state from
tributes are being changed. which to move forward or backward using the log.

We chose simple undo logging for Wayback because

4 Design Issues we felt that for our use cases – reverting mistakes made
in editing programs and documents – we would typical-
We encountered several issues while designing and im- ly have only to move backward by a small number of
plementing Wayback. The solutions we found and deci- versions. In light of other applications we would like to
sions we made have defined what Wayback is now. support (see Conclusion), we are reconsidering our log-
ging model.

3
 test that compares using Wayback FS to using manual
4.3 Use of FUSE checkins with RCS.

Once we had decided on a user-level approach, we next These tests were all run on three test systems:
considered how to interact with the kernel. At the time
we started development, FUSE was still in its early • Machine A: AMD Athalon XP 2400+ with 512
stages (we started with FUSE 0.95), but being able to MB of RAM using an internal 2.5 inch notebook
avoid kernel development altogether was very tempting hard drive.
to us since we wanted to concentrate on the versioning
mechanisms. The FUSE kernel module provided us • Machine B: Intel Pentium 4 2.2 GHz with 512
with the level of access we needed on a modern Linux MB of RAM using an external USB 1.1 disk
kernel. FUSE proved to be relatively stable and easy to (1.5 MBps).
use.
• Machine C: Intel Celeron 500 MHz with 128
Early versions of FUSE did not provide an upcall for MB of RAM using an internal 2.5 inch notebook
the close() system call. This lack would have made it hard drive.
impossible to create new versions on close, as in VMS.
Fortunately, we had determined to do write-level ver- All of the tests were run under Linux kernel 2.4.20 or
sioning. However, it still indirectly affected Wayback's 2.4.22.
design. In particular, without close() calls, managing
file descriptors for log files is made unnecessarily diffi- For comparison, another file system was built on top of
cult. FUSE before tests were run. This file system simply
redirects requests from the mounted file system through
to the underlying file system, acting as a pass-through.
4.4 Path Redirection This file system is used to identify the performance hit
taken solely by the FUSE system, and isolate the perfor-
After deciding to use FUSE, we quickly came upon an- mance loss from versioning. We consider the following
other issue. FUSE is designed only to provide a destina- file systems:
tion path for the file system, and not a source path to
mount there. The examples for FUSE either remount an • ext3: the out-of-box ext3 file system
entire directory structure beginning in the root directo-
ry, or provide their own root from a different source • ext3+fuse: ext3 run through our pass-through
such as memory. FUSE file system

We decided that we wanted to have redirection from • ext3+ver: Wayback FS running on top of ext3
any path, not just the root directory, so we had to imple-
ment a work-around. Wayback takes different com- These configurations were used for our Bonnie and An-
mand-line arguments from other FUSE file systems, and drew tests. In comparing to RCS, we compared
then modifies those arguments before passing them on “ext3+ver” to “ext3”, where the files in question were
to FUSE. We then use the information from those argu- periodically committed using RCS.
ments to modify every path given to Wayback from
FUSE, redirecting it to the “real” path. We did not run any tests on the performance of revert-
ing files, because it is not an everyday occurrence and
shouldn't matter as much as reading and writing perfor-
5 Performance Evaluation mance. Reverting or extracting a state from a file should
take at the most seconds if not less than a second. Disk
A variety of performance tests were run on Wayback FS space usage does increase when reverting files depend-
to evaluate its performance. These tests include Bonnie ing on the size of the reversion, because Wayback does
[Bonnie], which performs various operations on a very not remove the reverted entries from the log. Rather it
large file; the Andrew Benchmark [Andrew], which runs them backwards on the file, creating more entries
simulates the operation of normal file systems; and a in the log.

4
 Machine B: Bonnie Performance
5.1 Bonnie 1100
1000
Bonnie was originally created by Tim Bray to identify 900
bottlenecks in file systems. It does so by creating a very 800
large file, large enough to require disk access rather 700
600

KB/s
than caching, and reading from/writing to that file as ext3
500
fast as it can. ext3+fus
400 ext3+ver
300
200
5.1.1 Bonnie Implementation 100
0
Bonnie is implemented as a single C program. The pro- Write Write Rewrite Read Read
per per K/sec per per
gram takes arguments for the size of the file it will use charac - block charac - block
and the path where it will be stored. Bonnie then creates Performance Metric
the large file and performs many sequential operations Figure 2. Bonnie Performance on Machine B
on it, including writing character by character, writing
block by block, rewriting, reading character by charac- Machine C: Bonnie Performance
ter, reading block by block, and seeking. For this test, 18000
Bonnie was run with a file size of 1 GB. 16000

14000
12000
5.1.2 Bonnie Results 10000
KB/s

ext3
8000 ext3+fus
Figures 1-3 show the performance of the different Bon-
6000 ext3+ver
nie phases on the three machines. For each phase and
machine, we compare ext3, ext3 via our pass-through 4000

FUSE file system, and ext3 with Wayback versioning. 2000

The performance metric is in KB/s as measured by Bon- 0

Write Write Rewrite Read Read
nie. The point is to measure how much performance is per per K/sec per per
lost by using Wayback and how it breaks down into charac- block charac- block
ter K/sec ter K/sec
FUSE overheads and the actual costs of Wayback. Fig- Performance Metric
ure 4 shows the CPU costs, in terms of percentage of Figure 3. Bonnie Performance on Machine C
CPU used as measured by Bonnie.
Bonnie Overheads
100
Machine A: Bonnie Performance 90

18000 80
70
16000
60
% CPU

14000 ext3
50 ext3+fus
12000 ext3+ver
40
10000
KB/s

30
ext3
8000 ext3+fus 20
ext3+ver 10
6000
0
4000 Machine A Machine B Machine C
2000 Machine
0 Figure 4. Bonnie Overheads
Write Write Rewrite Read Read
per per K/sec per per
charac- block charac- block It is important to point out that in some cases layering
Performance Metric ext3 below FUSE actually increases its performance.
Figure 1. Bonnie Performance on Machine A We expect that this is due to buffering effects as there is

5
now an additional process which can buffer. Addition- run them with any set of files. It can also run the test
ally, the overheads shown in Figure 4 are slightly mis- multiple times and print a summary.
leading. Bonnie is measuring the system and user time
it uses, but does not count the time spent in the Way- The phases of the Andrew Benchmark are designed to
back server on its behalf. emulate everyday use of a file system. The phases are
all done using the source directory of a program, and in-
For block writes in Wayback, we see performance im- clude:
pacts in the range of -2% to -40% compared to un-
adorned ext3, depending on the speed of the disk and • Phase 1: Create five copies of the directory structure
the machine. For block reads, the performance impact in the source tree.
is +5% to -32%. Character writes are impacted -3% to
-50%, while the character read impact is -10% to -30%. • Phase 2: Copy all of the files from the source tree
In re-writing, where would expect to see the maximum into the first set of directories created.
impact, the range is -30% to -70%.
• Phase 3: Stats each file using `ls -l`.
The largest impact on write speed is on machines with
fast disks, particularly those that also have slow proces- • Phase 4: Read each file using grep and wc.
sors. The largest impact on rewrite speed is on ma-
chines with slow disks, which is to be expected as • Phase 5: Compile the source in the test tree.
rewrites will include additional data to be written to the
logs. Read speed is maximally affected on slow ma- The source that we used is that of the window manager
chines with fast disks. In many cases, a large portion, ION. Each phase was executed 1000 times to get accu-
often the majority of the performance impact is due to rate results. As before, we ran the benchmark three
FUSE rather than versioning. times on each time, once with the ext3 file system, once
with the pass-through file system on ext3, and once with
Wayback FS on ext3.

5.2 Andrew Benchmark

5.2.2 Andrew Results
The Andrew Benchmark, although quite old, is com-
monly used to measure the performance of file systems. Figures 5-7 compare the performance of the different
It performs operations similar to those performed every file systems for each phase on each machine. The per-
day on file systems, including making directories, copy- formance metric is the average wall-clock time to run
ing files, stating and reading files, and compiling a pro-
gram.
Machine A: Andrew Performance
1100
5.2.1 Andrew Implementation 1000
900
The original Andrew Benchmark was written on and de- 800
signed for Sun computers. It consists of a makefile that 700
Time (ms)

executes operations in five phases, ending in the compi- 600

Ext3
lation of a program. The program used in the bench- 500 FUSE
400 Wayback
mark will only compile on Sun systems however. The
Andrew benchmark also only runs each phase once, and 300

does not delete the files it creates. 200

100

Because of these limitations, we rewrote the Andrew 0

Phase Phase Phase Phase Phase
Benchmark in Perl. The program runs the same phases 1 2 3 4 5 / 20
as the original Andrew Benchmark, except that it can
Phase
Figure 5. Andrew Performance on Machine A

6
 tion (Phase 5), the impact of Wayback is very small
Machine B: Andrew Performance (15%) on all three machines.
2250

2000
That the performance impact on compilation is marginal
suggests that Wayback could be used very effectively in
1750
the edit-compile-debug loop of program development or
1500 document preparation with tools such as LaTeX.
Time (ms)

1250
Ext3
1000 FUSE

750
Wayback 5.3 RCS Comparison
500
In order to test the effectiveness of a versioning file sys-
250 tem, it is necessary not only to compare it to other file
0 systems, but to compare it to other methods of version-
Phase Phase Phase Phase Phase ing. For this reason we have constructed a test that com-
1 2 3 4 5 / 20
pares different operations on Wayback FS with similar
Phase operations using RCS on an ext3 file system.
Figure 6. Andrew Performance on Machine B

Machine C: Andrew Performance 5.3.1 RCS Implementation

3000
2750 The RCS comparison is implemented as a Perl script
2500 that runs through a variety of tests multiple times on
2250 both an RCS system and Wayback. The test records the
2000 time taken in each case as well as the disk space used.
Time (ms)

1750
1500 Ext3
1250 FUSE The RCS comparison runs three modes of testing and
1000
Wayback produces separate output for the three modes:
750
500 • Mode 1: Random seeks within a binary file fol-
250 lowed by writing a specified amount of random data.
0 This is designed to emulate normal binary file use.
Phase Phase Phase Phase Phase We used 1 MB binary files and 1 KB writes.
1 2 3 4 5 / 20

Phase • Mode 2: Read an entire binary file into memory,

Figure 7. Andrew Performance on Machine C change a specific number of randomly chosen loca-
tions with a specified amount of random data, then
each phase. Phase 5 (Compilation) times have been di- write the file back to disk. This is similar to the op-
vided by 20 to fit on the graphs. eration of some databases. For this test we used 1
MB files, 1 KB writes, and randomly between 5 and
There are several takeaway points from these graphs. 20 writes per iteration.
First, the largest performance impact of Wayback is on
directory creation (Phase 1). Second, Wayback increas- • Mode 3: Randomly choose a line in a text file,
es the time to run the write-intensive copy phase (Phase change a specified number of lines randomly using
2) by between a factor of two and a factor of four. The English words, truncate the file and write everything
largest impact is, not surprisingly, on a machine with a after the point at which it began changing lines. This
slow disk. Wayback has negligible impact on the stat test uses a dictionary file to construct files. This is
phase (Phase 3), except on very slow machines. The designed to emulate text editing, including changing
impact on reads (Phase 4) is relatively low (30%) re- configuration files and writing code. For this test we
gardless of the machine or disk. Finally, for compila- used files of 2000 lines, 20 words maximum per

7
 line, and changed randomly between 1 and 5 lines
per iteration. Machine C: RCS Performance
110
Each mode in this test was run for 100 iterations with a 100
file, and the whole ensemble was repeated 10 times with 90
different files. Wayback logged every operation as 80
normal. For RCS, we committed the file periodically, 70

Time (s)
varying the period. 60
50 Mode 1
Mode 2
40
Mode 3 x 10
30
5.3.2 RCS Results 20
10
Figures 8-10 show our results. As before, each Figure 0
corresponds to a particular machine. Three curves, one Ve RC RC RC RC RC RC RC RC RC RC
for each mode, are included. Times for the third mode rsi S 1 S 2 S 3 S 4 S 5 S 6 S 7 S 8 S 9 S
on 10

Set
Machine A: RCS Performance Figure 10. RCS Performance on Machine C
50
45 have been multiplied by 10 to fit on the graphs. The
40 vertical axis is the time required to run the mode, while
35 the horizontal axis is the test set. The left-most test set,
marked “Version” is for Wayback. The remaining test
Time (s)

30
25 sets are for RCS with varying period. For example,
Mode 1
20 Mode 2 “RCS 1” corresponds to RCS commits done after every
15
Mode 3 x 10 operation, which is equivalent to what Wayback is do-
10 ing, while “RCS 6” corresponds to RCS commits done
5 after every 6th operation. As the period increases, we
0
amortize more and more of the overhead of using RCS
Ver RC RC RC RC RC RC RC RC RC RC and get closer to the performance of Wayback.
sio S 1 S 2 S 3 S 4 S 5 S 6 S 7 S 8 S 9 S
ne 10
It is clearly the case that Wayback performs far better
Set than RCS at comprehensive versioning. An interesting
Figure 8. RCS Performance on Machine A trend is that for slower processors the difference be-
tween Wayback and RCS is greater, and for slower
Machine B: RCS Performance disks RCS nearly catches up to Wayback.
60
55 The results show that except in the case of a very slow
50 disk, Wayback performs better with single binary writes
45 (Mode 1) even if RCS is used with a period of 10. On
40
an average system, Wayback performs about as well as
Time (s)

35
30
using RCS every other time when writing the whole bi-
Mode 1
25 Mode 2
nary file (Mode 2). Using Wayback with text on an av-
20 Mode 3 x 10 erage system is similar in performance to using RCS
15 about once every four changes.
10
5
0
In terms of disk space use, the results are quite differ-
Ver RC RC RC RC RC RC RC RC RC RC
ent. For the single binary writes (Mode 1), Wayback us-
sio S 1 S 2 S 3 S 4 S 5 S 6 S 7 S 8 S 9 S es much less disk space than RCS. For writing the
ne 10
whole binary file (Mode 2), Wayback uses 25 to 30
Set times as much space as RCS. For text changes (Mode
Figure 9. RCS Performance on Machine B

8
3) Wayback uses about 20 times as much space as RCS. be simplified – we would have only to transfer the redo
These results are summarized in Table 1; sizes are log records that the remote log did not already have and
shown in bytes and are the average from 10 runs. Disk then redo them. For situations where a single large file
space is not dependent on the test system, so results are migrates among multiple sites but is accessed at one site
only shown from Machine A. at a time – virtual machine image migration for example
– such synchronization might prove to provide dramati-
File Type Mode 1 Mode 2 Mode 3 cally faster migration times.

Versioned 1157456.4 106347428.0 2182218.0 References

RCS Period 1 2242325.4 3856521.8 101062.2
[CVS] D. Gunne, et al, Concurrent Versioning System,
RCS Period 2 2237020.7 3779180.4 96134.2
http://www.cvshome.org
RCS Period 3 2233854.1 3731427.8 94336.4
[RCS] F. Tichy, Software Development Control Based
RCS Period 4 2234384.4 3719578.2 93597.1
On System Structure Description, PhD. Thesis,
RCS Period 5 2233716.4 3700853.4 93095.3 Carnegie Mellon University, 1980.
RCS Period 6 2227924.3 3621657.1 92375.5
[Andrew] J. Howard, et al, Scale and Performance in a
RCS Period 7 2230300.3 3635107.2 92321.2 Distributed File System, Transactions on Computer Sys-
RCS Period 8 2227552.2 3590195.5 91960.0
tems, Volume 6, February 1988.

RCS Period 9 2231124.4 3625548.8 92060.8 [Bonnie] T. Bray, The Bonnie Benchmark, http://www.-
RCS Period 10 2232218.7 3629717.4 92045.2 textuality.com/bonnie

Table 1. RCS Storage Costs [Elephant] D. Santry, et al, Deciding When to Forget in
the Elephant File System, Proceedings of the Sympo-
sium on Operating System Principles (SOSP 1999).
6 Conclusions [VersionFS] A Stackable Versioning File System,
http://www.fsl.cs.sunysb.edu/project-versionfs.html
We have described the design and implementation of
Wayback, a comprehensive versioning file system for [CVFS] C. Soules, et al, Metadata Efficiency in a Com-
Linux. Wayback is implemented as a user-level file prehensive Versioning File System, Proceedings of the
system using FUSE. When running on top of the stan- Conference on File and Storage Technologies (FAST
dard Linux ext3 file system, its overhead is quite low 2003).
for common modes of use.
[VMS] K. McCoy, VMS File System Internals, Digital
We are considering several extensions and applications Press, 1990.
for Wayback. First, if the underlying file system does
not support transactional writes, they could be forced by [Log] M. Rosenblum and J. Ousterhout, The Design
Wayback through sync operations. Second, it appears and Implementation of a Log-Structured File System,
that a file system that never garbage collects its undo ACM Transactions on Computer Systems, 10(1), 1992,
log would naturally perform very well when running on 26-52.
top of, or incorporated into a log-structured file system
[Log]. Third, if Wayback used an undo/redo, it would [UNDO] H. Garcia-Molina, et al, Database Systems:
be straightforward to go forward in time as well as The Complete Book, Chapter 17, Prentice Hall, 2002.
backward. Fourth, hierarchical version numbers and
undo/redo logging would permit branching. Of course, [FUSE] M. Szeredi,, Filesystem in USEr space,
it is not clear whether it would be any less painful to http://sourceforge.net/projects/avf
handle merging in the file system than in, say, CVS. Fi-
nally, given undo/redo logs and version numbers, keep-
ing large files synchronized among multiple sites would