<i>"Tux3 does not normally update the media view of its filesystem tree even at unmount. Instead, it replays the log on each mount. One excellent reason for doing this is to exercise our replay code. (You surely would not want to discover replay flaws only on the rare occasions you crash.) Another reason is that we view sudden interruption as the normal way a filesystem should shut down."</i><p>For those who are intrigued, this general philosophy is called "crash-only software" (though I don't know if the Tux3 guys take it to the extremes) and is pretty nifty when you can get away with it:<p><a href="http://lwn.net/Articles/191059/" rel="nofollow">http://lwn.net/Articles/191059/</a>
I love the emphasis on low CPU usage and not waiting for IO put into the design of the file system. The front/back split of the implementation makes a whole lot of sense. I wonder if any of these ideas are possible to implement in btrfs.