I will be continuing to commit bits and pieces of HAMMER, but note
    that it will probably not even begin to work for quite some time.

    I am still on track for it to make it into the end-of-year release.
    Mostly I just needed to clear my plate (my source working set) to keep
    track of the various major segments of the work without going completely
    batty.

    Only the A-list code is reasonably well tested so far, because
    newfs_hammer uses the same code.  The B-Tree code cannot be tested until
    I get more of the VFS infrastructure in place.  I expect that to be
    fairly straight-forward since I will be able to do a lot of testing
    with a one-cluster filesystem (i.e. without the B-Tree cluster
    extension coded).

    The most difficult piece in the entire design is the B-Tree deletion code
    and that is now coded.  I decided to go with a forward-iteration for both
    insertions AND deletions, which is THE most difficult B-Tree algorithm to
    implement.  But the huge advantage is that I will be able to remove
    the cluster lock in the future and lock B-Tree nodes as I go down without
    getting into deadlock situations, which is very SMP friendly.

    My B-Tree implementation also allows HAMMER to cache B-Tree nodes
    and start lookups from any internal node rather then having to start at
    the root.  You can do this in a standard B-Tree too but it isn't
    necessarily efficient for certain boundary cases.  In my implementation
    I store boundaries for the left AND right side which means a search
    starting in the middle of the tree knows exactly where to go and will
    never have to retrace its steps.

    Whew.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

Speaking of on-disk B-Trees, ReiserFS' biggest problems are all based
on its use of flexible B-Trees. For instance, the difficulty of
correctly rebuilding the tree if a node is damaged, and correctly
detecting if a ReiserFS system is hosted on a file in another
(supposedly damaged) ReiserFS system, are noted as big problems that
are supposedly solved for Reiser4. Are there likely to be similar
issues in Hammer for the time being, or have you already planned far
ahead for these cases with extra information in the nodes?

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia