linux-kernel - Tux3 Report: It's What Next time once again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 3 Oct 2008 22:55:12 -0700
From:	Daniel Phillips <phillips@...nq.net>
To:	linux-kernel@...r.kernel.org
Cc:	tux3@...3.org
Subject: Tux3 Report: It's What Next time once again

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/