a new way to hang 7.0
dillon at apollo.backplane.com
Mon Jan 7 14:11:50 PST 2008
: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
: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
: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 :-).
<dillon at backplane.com>
More information about the freebsd-current