What is ext3cow?

Ext3cow is a stand-alone disk file system, (e.g. ReiserFS, HFS, NTFS) based on ext3, that supports versioning through copy-on-write and a time-shifting interface.

Why is it called ext3COW?

COW stands for copy-on-write, the mechanism used to implement block versioning.  It works like this:  When you make a change to a file, instead of writing the new data over the old data, we preserve the old data, and allocate new data blocks for the new data.  Only the changed data is given a new allocation, allowing similar data blocks to be shared between versions — this minimizes the amount of data required to support versioning.

What are the costs?

For every version of a file that exists, an inode must exist to reference it, so compared to ext3, there’s a small increase in the amount of metadata required to support versioning.  Experimental results show that the metadata overhead ranges from 5% - 15%, depending on how frequently one takes snapshots.  Further, because fewer data blocks are reallocated, ext3cow requires more actual disk space then its sister file system, ext3.  Again, this overhead is dependent upon how frequently a user takes snapshots and how much data they are modifying.

How expensive is taking a snapshot?

Almost free.  A snapshot simply updates the file system’s epoch counter, located in the super block.  It copies no data and only performs a sync to flush dirty buffers.  The actual version creation is done when you perform an IO operation that modifies a file, e.g. a write, chmod, truncate, etc.

What about temporary files?

Files that are created and destroyed in the same epoch, i.e. no snapshot is taken, are actually deleted.  This helps prevent useless temporary files from getting captured in the past, minimizing overhead.

How do I really delete a file in the past?

Currently, there is no mechanism to do so.  However, one existed in the 2.4 version of ext3cow, so it’s just a matter of time until it makes its way into 2.6.  Check the Bugs and TODOs page for planned enhancements.

The time-shifting interface doesn’t look very intuitive. What’s up with that?

The way you access files in the past is with the ‘@’ token followed by an epoch number.  We fondly refer to the ‘@’ token as “The Flux Capacitor” for various, non-trademark-infringing reasons.  This token is customizable.  The epoch number is the number of seconds passed since The Epoch (00:00:00 UTC, January 1, 1970); see the gettimeofday() man page.  This may seem a little non-intuitive at first, but we believe any fancier syntax should be supported by the shell, not the file system.  This approach is similar to how access and creation time is handled.  Take a look at Time-Traveling File Manager if you’re interested in a GUI interface to ext3cow.  That being said, we are looking at supporting some common macros in a future version, for example: @yesterday, @lastweek, @lastmonth, etc.

Can I look at directories in the past?

Sure.  You can access past directories in the same way you access past files, with the ‘@’ token.  For example, you can say: cd /home/zachary@1057845484 and be presented with how my home directory looked at 9:58AM, July 10th, 2003.  A neat trick is to create symbolic links into the past.  For example: ln -s /bin@1057845484 /bin.preinstall would be useful if you wanted to later diff the contents of your /bin directory.

Are snapshots automatic?

No, not by default, but a simple cron job takes care of that.  Or, try Tim Post’s set of ext3cow tools.

How is time-shifting different then using CVS, SVN, VMS... versioning?

To be sure, ext3cow is not the first versioning file system.  Ext3cow wouldn’t be here if it wasn’t for VMS, TOPS, CedarFS, FFS, Elephant, LFS, CVFS, AndrewFS, WAFL, SnapFS, Venti, Spiralog, Plan-9, Wayback, VersionFS, and all the others I can’t remember right now.  There are differences between all these systems and ext3cow, however.  Many systems use numbered versions, e.g. revision 101 of file foo, version 10 of file bar, etc.  This is fine, but doesn’t give a user any natural concept of time or relation to the other files around it.  With ext3cow, a user may travel back to any arbitrary point in time, and see what a single file or the entire file system looked like.  In our opinion, this is a more powerful way of doing versioning, because not only does one implicitly get the numbered versions, a la CVS/SVN, but you also get an understanding of how and when that file existed.

Does this mean my file system will be cluttered with past versions?

No.  Your current view of your file system should look no different than a non-versioning file system.  Past versions are accessed through the ‘@’ token.  Further, even when looking at past namespaces, the file names are not modified, and will look exactly as they did when the snapshot was taken.

Can the same file name exist in different contexts?

Yes.  If you create a file, take a snapshot, and remove the file, you may then create another file with the same name, while still preserving the past data associated with that name.  Now you have two files with the same name, but in different scopes of time.

How do I bring a deleted file back?

Find the file in the past version and simply copy it to the current view.  For example:

cp /home/zachary/ext3cow_todo.txt@1057845484 .

Add the -r switch, and this works for entire directories too.

What’s the performance like?

We’re still working on putting up some formal performance numbers, but preliminary results show that ext3cow is performance-equivalent to ext3.

How are ext3 and ext3cow different?

We started with the ext3 code base, renamed all the ext3 functions to ext3cow functions, and modified certain aspects of the file system’s functionality and structure to support versioning.

Are ext3 and ext3cow compatible?

No.  They have different on-disk metadata structures.  At some point there will be an ext3 to ext3cow conversion tool.  (Of course, cp provides a similar functionality!)

My journal is aborting.  What’s wrong?

If you’re seeing an error like this:

journal_bmap: journal block not found at offset 12

it’s probably due to at least one of the following reasons:

1. • You didn’t format the ext3cow partition properly.  Make sure you’re using the mkfs.ext3cow provided by this site, and make sure it’s named mkfs.ext3cow.  If, during format, you don’t see a line that says: Writing super block with epoch number:, you’re not using the correct mkfs.
   

2. • Make sure your file system epoch number looks sane during mkfs and during mount (check the kernel messages for the latter).  Midnight of Jan 1, 2007 has the epoch number: 1167627600.  If you’re nowhere near that, something is amiss.
   

3. • Be sure you mount the file system as ext3cow and not ext3.  This can be done by giving the ‘-t ext3cow’ switch to the mount command.  If you see ?’s for directory names, you’ve probably mounted it as ext3.
   

I have a frequently asked question.  Where should I send it?

The ext3cow-devel mailing list is the best option.