Contact Info

(for those who care)

Instant Gratification   

Wed, 05 Oct 2005

The Time-Travelling Filesystem and Other Oddities

So Slashdot had a story about lossless filesystems and the conversation turned pretty interesting (at least my part of it, anyway).

…I want a (s)low-performance, bloated, version controlled, roll-back featured, viewcvs.cgi enabled file system for my /home/rames (or at least /home/rames/documents).


My frustration comes from having a few occasions where I have various word doc’s or presentations that I’d like historical copies of but of course I’m doing the “Doc-1.txt”, “Doc-2.txt” business which is utterly ridiculous considering the technical prowess of the world right now (unfortunately I’m not quite ready to go full SVN-homedir yet).

The comment spawned a lot of replies (12 at last count!) and turned up some very interesting links. The initial post talked about “log-structured filesystems”. Basically, instead of modifying previously written data, you add a new entry saying: “remember that file back there, here are the changes that I want to make to it now”. Great write performance in some scenarios, terrible read performance in some scenarios and “oops, don’t run out of disk space cuz that’ll mess us up.”

In my post, I linked to FUSE and it turns out that FUSE already has a filesystem plugin called Wayback (looks like a log / undo-log based system). And a couple of people mentioned the Plan9 Venti filesystem documentation (fascinating, fascinating, fascinating!). But what really piqued my interest from a pragmatic approach (meaning available now) was ext3cow and The Time Traveling File Manager [cue cheezy sci-fi echo].

But seriously. COW stands for “Copy on Write”, basically optimizing a system for the case where no modifications are made to objects. Instead of making a “heavy copy” up front only make a “heavy copy” when the object in question is modified (although I don’t agree with the linked paper’s conclusions in all cases). You’ll see Copy on Write in the Linux Kernel, JVM’s, SVN, various other scripting languages, etc. It looks like ext3cow is taking that same approach to filesystems with only a 5% overhead?!?

And then top it off with the Time-Travelling File Manager, which is dead on with my imagined perfect interface on top of my filesystem. Sprinkle in a little bit of git goodness and some more nifty visualizers add hackers and stir for a few years and life will be pretty good.

The Time-Travelling File Manager

In other news, it looks like I missed making a blog entry in September so you’ll have to accept the awesome quality of this one as payment. If you don’t want to accept the awesome quality of this one, here’s a quick post-script:

New tests for

Running recently developed tests against chess:

checkgame - test_config ok
checkgame - test_init ok
checkgame - test_status ok
checkgame - test_force FAIL
  - validate that player was skipped
checkgame - test_nuke ok

5 tests run
1 failure
0 errors.

…and against Chinese Checkers:

checkgame - test_config FAIL
  - All needed keys were found
  - version should be non-zero
checkgame - test_init FAIL
checkgame - test_status FAIL
  - should be player 'a's or player 'b's turn
  - game should be returning timestamp
checkgame - test_force FAIL
  - validate that player was skipped
checkgame - test_nuke FAIL

5 tests run
32 failures
0 errors.

Lots of work to do, but at least I’ll know when I’m done, and it should be re-usable to dominoes when I decide to fix those last three corner cases. And maybe this will encourage Chris and me to figure out how to tweak per-game behaviour of forceUrl (and to start talking about dropOut:{player}, but one thing at a time).

00:54 CST | category / entries
permanent link | comments?

Like what you just read? Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Thanks for Visiting!