lkml.org 
[lkml]   [2008]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectTux3 Report: It's What Next time once again
Date
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:

http://lkml.org/lkml/2008/7/23/257

Other pieces of the puzzle were described as part of the discussions
with Matt Dillon comparing the designs of Tux3 and Hammer[1]:

http://tux3.org/pipermail/tux3/2008-July/000012.html
"Comparison to Hammer fs design"

http://tux3.org/pipermail/tux3/2008-July/000014.html
http://tux3.org/pipermail/tux3/2008-July/000018.html
"Two kinds of atomic commit"

Many thanks to Matt for forcing me to be clear about certain essential
details.

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.

Regards,

Daniel

[1] By the way, somebody should port Hammer to Linux.


\
 
 \ /
  Last update: 2008-10-04 07:57    [W:0.390 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site