Linked by Thom Holwerda on Sun 14th Oct 2007 14:52 UTC, submitted by Oliver
BSD and Darwin derivatives Matthew Dillon writes: "I am going to start committing bits and pieces of the HAMMER filesystem over the next two months. Note that the filesystem will not be operational until we get closer to the 2.0 release in December so these bits and pieces will not be tied into buildworld/buildkernel until then." Features: maximum size of half an exabyte, infinite snapshots, limited only by retention policy, streaming backups, asynchronous transactional support (no long fscks to check disk state). Dillon also explains why he chose not to use Sun's ZFS.
Thread beginning with comment 278131
To read all comments associated with this story, please click here.
Honk! Honk!
by Weeman on Sun 14th Oct 2007 15:50 UTC
Weeman
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.

RE: Honk! Honk!
by Zoidberg on Sun 14th Oct 2007 16:00 in reply to "Honk! Honk!"
Zoidberg Member since:
2006-02-11

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

Reply Parent Bookmark Score: 4

RE[2]: Honk! Honk!
by JonathanBThompson on Sun 14th Oct 2007 16:48 in reply to "RE: Honk! Honk!"
JonathanBThompson Member since:
2006-05-26

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.

Reply Parent Bookmark Score: 6

RE: Honk! Honk!
by dekernel on Sun 14th Oct 2007 16:12 in reply to "Honk! Honk!"
dekernel Member since:
2005-07-07

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.

Reply Parent Bookmark Score: 2

RE[2]: Honk! Honk!
by kaiwai on Sun 14th Oct 2007 16:48 in reply to "RE: Honk! Honk!"
kaiwai Member since:
2005-07-06

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.


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.

Reply Parent Bookmark Score: 2

RE: Honk! Honk!
by yorthen on Mon 15th Oct 2007 10:59 in reply to "Honk! Honk!"
yorthen Member since:
2005-07-06

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.

Reply Parent Bookmark Score: 2