HAMMER2 design in progress - 1-2 year time frame
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>
>
討論串 (同標題文章)
完整討論串 (本文為第 3 之 19 篇)：