DragonFly kernel List (threaded) for 2011-05
HAMMER2 design in progress - 1-2 year time frame
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
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.
On Wednesday, 11 May 2011, Matthew Dillon <email@example.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:
> 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
> 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.
> Matthew Dillon