Just before steam shot out of my ears, I was thinking that this all sounded really cool. I really like the new concept for PFS functionality.
Tim On Wed, May 11, 2011 at 10:44 AM, Matthew Dillon < [email protected]> 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 > <[email protected]> >
