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 <[email protected]> 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 >
