HAMMER2 design in progress - 1-2 year time frame

[Alex Burke <alexjeffburke@xxxxxxxxx>]

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.

On Wednesday, 11 May 2011, Matthew Dillon <dillon@apollo.backplane.com> wrote:
>     I'm almost done with the design stage for the HAMMER2 filesystem and
>     will soon begin coding.  The basic design document is here:
>
>         http://apollo.backplane.com/DFlyMisc/hammer2.txt
>
>         Lots of tech-speak inside, attach heat sinks to your brain!
>
>     I am going to caution that I expect it to take about a year to implement
>     most of the features (including the clustering bits which will be fully
>     integrated into the filesystem), and probably 2 years for it to reach
>     production stability.  HAMMER2 is not going to replace HAMMER1 any time
>     soon.
>
>     In addition, HAMMER2 is going to have two serious restrictions relative
>     to other filesystems.  (1) HAMMER2 will not support hardlinks.   And
>     (2) HAMMER2 has no physical way to resolve '..' and will depend on the
>     operating system's namecache to handle '..' (which DragonFly's will).
>
>     There are many reasons for these restrictions, but it mostly comes down
>     to the complexity of cluster cache coherency and mirroring protocols
>     (making hardlinks extremely difficult to implement) and support for
>     writable snapshots (making inode_num->physical translations and parent
>     pointers extremely difficult to implement).  It's kind of a
>     one-or-the-other problem.
>
>     HAMMER2 will also do away with the PFS concept, and instead any
>     subdirectory tree can be treated as a PFS and independently mirrored,
>     and also account for space & inodes used.
>
>     So HAMMER2 is going to have a lot of cluster-friendly features.  A
>     veritable ton, but in order to be able to implement those features
>     in a reasonable time frame with a reasonably low degree of complexity
>     I had to make the above two tradeoffs.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon@backplane.com>
>