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