DragonFly kernel List (threaded) for 2007-10
Re: HAMMER filesystem update - design document
: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
:Also, what, if any, will be the locking policy for multiple I/O threads
:accessing a single HAMMER filesystem? Shared/exclusive mutexes on the
:(Whomever invented early mornings does not deserve brownie points),
: Thomas E. Spanjaard
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