Daniel Phillips of the Tux3 file-system wrote on the Linux kernel mailing list this evening, "When something sounds to good to be true, it usually is. But not always. Today Hirofumi posted some nigh on unbelievable dbench results that show Tux3 beating tmpfs. To put this in perspective, we normally regard tmpfs as unbeatable because it is just a thin shim between the standard VFS mechanisms that every filesystem must use, and the swap device. Our usual definition of successful optimization is that we end up somewhere between Ext4 and Tmpfs, or in other words, faster than Ext4. This time we got an excellent surprise."
The attributed reason by Phillips for Tux3 being able to edge out the thin Tmpfs implementation is that the Tux3 front-end/back-end design can work atop CPUs and when some of the work is offloaded a-synchronously for the Dbench task, the situation turns quite positive.
The Tux3 developer added, "It is hard to overstate how pleased we are with these results. Particularly after our first dbench tests a couple of days ago were embarrassing: more than five times slower than Ext4. The issue turned out to be inefficient inode allocation. Hirofumi changed the horribly slow itable btree search to a simple 'allocate the next inode number' counter, and shazam! The slowpoke became a superstar. Now, this comes with a caveat: the code that produces this benchmark currently relies on this benchmark-specific hack to speed up inode number allocation. However, we are pretty sure that our production inode allocation algorithm will have insignificant additional overhead versus this temporary hack. If only because 'allocate the next inode number' is nearly always the best strategy."
Sadly though, the Tux3 file-system still has yet to be proposed for inclusion into the mainline Linux kernel. At least for now there's more hope held up for seeing Tux3 mainline rather than Reiser4 or ZFS. Another recent Tux3 accomplishment was initial FSCK support.