Re: a new way to hang 7.0

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Mon, 7 Jan 2008 14:11:38 -0800 (PST)
:OK, so you reject softupdates because it took time to mature and you
:assume it stopped improving when you stopped paying attention.
:
:How long do you think it will take for HAMMER to mature?  Realistically?
:How long will HAMMER be "a huge source of bugs in the system" before it
:stabilizes?
:
:Think back to when you started DragonFly.  How soon did you expect it to
:overtake FreeBSD in SMP performance?  And how long did it actually take?
:Actually, it never happened - DrangonFly doesn't scale at all across
:multiple cores, while FreeBSD 7 leads the pack.
:
:Perhaps you should adjust your expectations a bit.  I don't doubt that
:HAMMER will be a very interesting file system when it's stable, but I
:doubt very much that will happen any time soon.  In fact, I think it
:will take about as long for HAMMER to mature as it took for softupdates
:and SMPng.
:
:DES
:--=20
:Dag-Erling Sm=C3=B8rgrav - des_at_des.no

    Don't mistake the existance of the MP lock for a lack of SMP coding.
    All kernel coding done in DragonFly these days is SMP oriented because
    all the APIs are SMP oriented, whether the MP lock is held or not.
    We are better positioned there then you think we are.  If I am overly
    conservative when it comes to maintaining system stability, well,
    that's just a quirk of mine.  I don't feel there's much of a point to
    having cool bells and whistles if it also means getting crashes, or
    introducing untraceable and difficult-to-debug bugs.

    Personally speaking, if I had the chance to inherit FreeBSD's MP work,
    I wouldn't touch it with a ten foot poll.  Regardless of the performance
    you are getting out of it, your code base is a huge mess and it looks
    completely unmanagable to me.  You have had to deal with a continuous
    stream of bugs from the same subsystems for the last, what, five years?
    I attribute that directly to the ridiculous amount of complexity you
    have introduced to all levels of the kernel.  No thanks.

    With regards to softupdates verses HAMMER, I think you are trying
    to compare apples to oranges here.  Softupdates still has bugs because
    it is very, VERY complex and fragile code that only three people in the
    entire world understands well enough to work on.  HAMMER development
    is bounded only by its from-scratch implementation.  It is extremely
    well organized, extremely robust, well commented, and the bugs are a
    short-lived byproduct of development.  I expect it will become
    production ready very, very quickly once the remaining core work is
    completed (the on-the-fly recovery code and the long-term balancing
    code)...  just like every other major application I've written over
    the years has been.

    Kirk stopped working on softupdates years ago, the snapshot code is
    severely limited, and it hasn't removed the need for fsck.  Background
    fsck is still as dangerous to run as the day it was introduced, and
    the only softupdates work I see are attempts to fix bugs.  From my point
    of view softupdates is dead, and UFS2 is in no better shape if you can't
    fix the fsck issue (and I have grave doubts about its ability to scaleh
    given the linear nature of most of the cluster algorithms).  On top of
    that UFS has the same problems that it has always had.  The dirhash
    code is a bandaid at best.  I occassionally see people talking about
    building a log into UFS or resurrecting LFS.  It's possible to do but
    it would also be the end of the line for the filesystem.  The last gasp,
    so to speak.  I have followed every single commit made to softupdates
    since its inception.  Don't kid yourself.

    The major goal for DragonFly has been and always will be transparent
    clustering.  HAMMER and its transaction oriented record storage
    abstraction is one of three major components needed to being able to
    achieve that.  Above and beyond that, HAMMER solves at least half a dozen
    major infrastructure needs and it does it very cleanly.  It had better,
    it took me all of 2007 to design the sucker :-).

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>
Received on Mon Jan 07 2008 - 21:11:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:25 UTC