|| ||Daniel Phillips <phillips-AT-phunq.net>|
|| ||Tux3 Report: It's What Next time once again|
|| ||Fri, 3 Oct 2008 22:55:12 -0700|
|| ||Article, Thread
Today was one of those skate-in-the-dark kind of days here in Paradise,
but whereas the Tux3 cabal quite enjoys the occasional dimly lit
runabout in the concrete jungle, we make it a point not to keep you,
loyal readers, in the dark about upcoming Tux3 development directions.
The past three week's work made something of a liar of me, as we
completely ignored the task of integrating versioned pointers that I
had talked about earlier. Instead, the Cabal decided that we would be
better served by putting the effort into extents, in the interest of
benchmarking well right from the start.
In fact, Tux3 will never actually have versioned pointers, but rather
versioned extents, a much more ambitious proposition and messy enough
that we now plan to defer that coding until some time after the initial
kernel port, which is now expected to land with atomic commit and
extended attributes but without versioning. Another way of putting it:
I promised to cut corners by leaving something for later, and that
something is going to be versioning. Tux3 will thus first arrive in
kernel as more or less a functional equivalent of Ext3 (with bigger
limits and shiny atom thingies) instead of something more exotic.
Atomic commit is a biggish project in its own right. As with xattr
atoms and certain aspects of the extent strategy, we forge into
unexplored territory here with some new ideas on how to handle this
tricky task robustly and efficiently. The concept of forward logging,
which is just one part of the planned mechanism, was described in the
original Tux3 announcement:
Other pieces of the puzzle were described as part of the discussions
with Matt Dillon comparing the designs of Tux3 and Hammer:
"Comparison to Hammer fs design"
"Two kinds of atomic commit"
Many thanks to Matt for forcing me to be clear about certain essential
Now it is about time to put the pieces together to create a new
algorithm which one might call "Son of Phase Tree". The end goal of
this effort is to approach media speed for both data and metadata
commits, while controlling read fragmentation effectively.
 By the way, somebody should port Hammer to Linux.
to post comments)