: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