HAMMER update 15-Jan-2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    HAMMER work continues to progress well and most of the recovery code is
    written and working, but I hit a small hangup with the way spikes are
    implemented.

    Spikes give HAMMER the ability to forward a sub-range of keys in one
    cluster's B-Tree to another cluster.  Currently spikes are placed at
    internal nodes in the B-Tree in order to take advantage of the left and
    right bounds information available in those nodes.  Unfortunately the
    left and right bounds can change on the fly and this causes the target
    cluster's range to get out of sync with the originating cluster's range.

    It also introduces a few too many special cases, so I am going to be
    reworking the spike code in the next day or two.  Instead of storing
    the spike as a special case of a B-Tree internal node I will store it
    as to elements (left and right boundary elemnts) at the leaves of the
    tree, allowing them to be manupulated with standard B-Tree ops instead
    of special spike ops.

    Having the spikes represented with two leaf elements will also greatly
    simplify the remainder of the recovery code and the balancing code.

    I originally intended to use two leaf elements to represent spikes but
    I got all glowy-eyed at the prospect of just being able to use a
    single internal element with its left and right bounds and went down
    the wrong path there.

    In anycase, work continues :-)

					-Matt