To read all comments associated with this story, please click here.
Maybe, or it may go faster for him. There's the old saying about too many chefs in the kitchen. Look at how many people were working on Vista and how long it took. The more people you have working on a project, the more you have to wait on others, more confusion, and more bickering.
Edited 2007-10-14 16:01
The concern for backwards compatibility is a huge reason for Vista taking as long as it did, making as many changes as it did: this filesystem only needs to be sufficiently compatible with the virtual file system interface, and implement according to that general contract: in no way can Vista and any single filesystem be comparable in scope, complexity, or manpower required to do things correctly. You might as well foolishly start comparing the development of this filesystem (or any other filesystem) that needs to have the VFS compatibility with say, KDE going between one major revision number and another, as that is a similar comparison to what you're making.
Nonetheless, there's often a great advantage to being only a single person in charge of a system, and also a disadvantage: a single person won't (hopefully) end up creating something that reeks of "design by committee" but by the same token, it's entirely possible that a single developer will have one or more huge blindspots that causes them to miss something needed or mess up in some spectacular way that'd be prevented by having more than one person involved.
On face value you might appear to be correct, but you have forgotten an important point. Matt is sitting in a very unique position when it comes to implementing this. He has free access to make the changes necessary in any part of the system he needs without much worry of requiring or maintaining backwards compatibility. Make no mistake, that can make all the difference when it comes to implementing such deep-rooted technologies quickly.
I also believe that this type of "filesystem" (I put quotes because this level of functionality goes far beyond a typical filesystem) has been his goal since the inception of DragonFlyBSD so all of the work to date has been done to facilitate the addition of HAMMER.
And more importantly, the situation he is in, he doesn't have to contend with the office politics with marketing breathing down the programmers necks to implement zyx feature because it has foobah buzzword.
ZFS is also very much in its infancy; this isn't a bash against it, but having had a look at the various bugs that have come up regarding it, I'd sooner feel more comfortable sticking with something like UFS.
I'm not an expert on the subject, but I'd say that ZFS consists of two parts, the FS and the "IO stack". The FS is the actual filesystem (on disk data layout etc.) while the IO stack is the rest that makes ZFS special.
HAMMER is very similar in that it will also have two parts, the FS and the rest. The actual FS does not have to take particularly long to develop if you are familiar with FSes (like Matt) and do not try to make something truly revolutionary. The rest is probably the harder part, but the idea of a clustered file system is not new and Matt has been working a few years towards this goal and I would guess that a lot off the grunt work is already done.
As an example, the (FS independent) journaling was implemented as far back as 2005, and it is my understanding that it will play an important role when replicating across machines. Also, in February Matt posted an initial outline of HAMMER, so for those who claim that it will be done in record time: I'm not so sure, this is something he has been working on for quite some time now.







Member since:
2006-03-20
Nice goals set for his project. But while he expects to implement a working version ready for beta testing within record time, ZFS had more than one person working on it for like three years and it's still missing some features. So I don't think he can deliver within his intended timeframe.