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).
[source…]
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 DarwinGames.com
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?