HAMMER filesystem update - design document

[Matthew Dillon]

:Any specific reason not to go with a B+-Tree or B#-Tree which have shown 
:to have advantageous effects?

    A B+Tree is possible.  I am not familiar with a B#Tree but if you mean
    the variation where a node is split before it becomes full instead of
    when it becomes full (which can improve performance when nodes are
    individually locked), then that is a possibility too.

    The issue with a B+Tree verses a B-Tree is that there needs to be
    sufficient space in the B+Tree node to be able to store both record
    information and the pointer to the next BxTree layer.  It turns out
    that we barely have enough space in the current structural design
    for both.

:Also, what, if any, will be the locking policy for multiple I/O threads 
:accessing a single HAMMER filesystem? Shared/exclusive mutexes on the 
:cluster level?
:
:(Whomever invented early mornings does not deserve brownie points),
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    It will be cluster-by-cluster to begin with.  I don't expect it to cause
    any issues, the BxTree in each cluster will be fairly compact and well
    cached and, most importantly, nearly all write I/O can be asynchronous
    so locks simply will not be held all that long.

    Eventually it will be possible to use inherent buffer cache locks to
    lock the BxTree operations but its a little dicey to try to do
    that level of fine-grained locking by default due to the allocation
    model.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>