This came from:
   http://www.nist.gov/dads/HTML/bstartree.html
Here's another, referring to Knuth's original description:
   http://www.cise.ufl.edu/~jhammer/classes/b_star.html
> >To tell the truth, I haven't read your code that closely, sorry, but I got 
> >the impression that you're doing rotations for balancing no?  If not then 
> 
> What are rotations?
Re-rooting a (sub)tree to balance it.  <Pulls Knuth down from shelf>
For a BTree, rotating means shifting keys between siblings rather than 
re-parenting.  (The latter would change the path lengths and the result 
wouldn't be a BTree.)
So getting back to your earlier remark, when examined under a bright light, 
an HTree looks quite a lot like a BTree, the principal difference being the 
hash and consequent collision handling.  An HTree is therefore a BTree with 
wrinkles.
<reads more> But wait, you store references to objects along with keys, I 
don't.  So where does that leave us?
By the way, how do you handle collisions?  I see it has something to do with 
generation numbers, but I haven't fully decoded the algorithm.
Fully understanding your code is going to take some time.  This would 
go faster if I could find the papers mentioned in the comments, can you point 
me at those?
-- Daniel- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/