DragonFly BSD
DragonFly kernel List (threaded) for 2011-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: HAMMER2 design in progress - 1-2 year time frame


From: Tim Darby <t+dfbsd@xxxxxxxxxxxx>
Date: Wed, 11 May 2011 11:33:15 -0700

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 <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>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]