DragonFly kernel List (threaded) for 2007-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
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
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@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@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]