DragonFly kernel List (threaded) for 2011-05
Re: HAMMER2 design in progress - 1-2 year time frame
Didn't get the chance to say thank you for your reply - found it very
interesting and it definitely explained a few things.
It definitely think DragonFly is doing unique things with some very
novel approaches; best of luck with the implementation once it begins.
Thanks, Alex J Burke.
On 13 May 2011 16:10, Matthew Dillon <email@example.com> wrote:
> :I'm a DFBSD lurker and I certainly wouldn't profess to understand
> :everything in that document, but a comp sci degree means I just about
> :followed :)
> :I noticed you had decided not to store the versioned inodes in the
> :B-Tree, which I believe is what HAMMER 1 did. I was curious why that
> :was - I saw mention of not being able to have parent pointers in on
> :media structures, but want sure if it was related and what the impact
> :Otherwise, sounds pretty incredible; that any sub trees can be PFS,
> :writable snapshots and multiple roots are all ingenious.
> :Cheers, Alex J Burke.
> The B-Tree is a great indexing mechanism but it suffers from
> two big problems in HAMMER1.
> First it is very difficult to keep things organized for locality of
> reference. For example when you split a B-Tree node, the split node
> can wind up seriously far away from the original with regards to
> disk seek times. The seek inefficiencies are largely removed if one
> uses swapcache.
> Second and more importantly, manipulation of the B-Tree requires
> an UNDO FIFO (which HAMMER1 implements). The UNDO FIFO is one of
> HAMMER1's most complex bits of code and how other implications as
> well, such as having to hold dirty buffers locked to prevent the
> kernel from writing them out too early (the UNDO data has to be
> flushed first).
> HAMMER2 primarily addresses the second point. By chasing blocks
> all the way to the root HAMMER2 doesn't need an UNDO FIFO at all,
> and (theoretically) doesn't need special handling of the buffer
> cache by the OS because write ordering no longer matters. The
> disk flush sequence prior to updating the volume root is still
> necessary but it's still far less complex than HAMMER1's UNDO
> The trade-off is that HAMMER2 currently does not index its inode space
> by inode number (there being no B-Tree or other data structure to
> maintain such an index in), which is its primary reason for not being
> able to support hardlinks. On the plus side the B-Tree in HAMMER1
> could support only simple snapshots while the block referential model
> HAMMER2 will use can also support writable snapshots (i.e. snapshot