Re: HAMMER2 design in progress - 1-2 year time frame
Hi,
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 <dillon@apollo.backplane.com> wrote:
>
> :Hi,
> :
> :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
> :was.
> :
> :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
> 슠 슠sequencing.
>
> 슠 슠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
> 슠 슠forks).
>
> 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠 슠-Matt
>
討論串 (同標題文章)
完整討論串 (本文為第 5 之 19 篇)：