Why ZFS instead HAMMER

Hello.

After reading http://www.dragonflybsd.org/hammer/ I had a question - why FreeBSD has chosen for inclusion in the official base of ZFS filesystem (its development in the future on FreeBSD, as I understand it - is now in big question), rather than closer to the BSD world - HammerFS. Were there any special reasons?
 
For example ZFS's built in volume manager, HAMMER is 'just' a filesystem, You will not create any RAID5 or mirrored filesystem, its like UFS in that case, that is why DragonflyBSD incorporated Linux's LVM to do that part of the job.

From what I know HAMMER does not support compression or copies=N to keep N copies of a file, no deduplication or anything like that.

HAMMER is like CVS, any modifications to files are like changes to CVS, so when You modify a file mane times, You can 'browse' older version 'just like that', of course similar behaviour can be achieved in ZFS with snapshots, but its 'core' of HAMMER, not a feature like in ZFS.

Another thing that is worth mentioning is swapcache mechanism in DragonflyBSD, as ZFS has its own caching mechanisms, swapcache is DragonflyBSD's mechanism to 'counter' that of ZFS.
 
Guess back then, when the decision was made, hammer did not exist or had the features ZFS had at that point in time.
 
Here's my 2 cents worth. I have a DragonFLY VM running Hammer. In my day to day work, it seems hammer is faster than UFS or ZFS comparied to my Solaris X86 and FreeBSD VM's. If hammer would get rid of LVM and get it get it's own volume manager, it should be included in the FreeBSD kernel. BTW, I do not like Solaris's ZFS!
 
vermaden said:
For example ZFS's built in volume manager, HAMMER is 'just' a filesystem, You will not create any RAID5 or mirrored filesystem, its like UFS in that case, that is why DragonflyBSD incorporated Linux's LVM to do that part of the job.

From what I know HAMMER does not support compression or copies=N to keep N copies of a file, no deduplication or anything like that.

HAMMER is like CVS, any modifications to files are like changes to CVS, so when You modify a file mane times, You can 'browse' older version 'just like that', of course similar behaviour can be achieved in ZFS with snapshots, but its 'core' of HAMMER, not a feature like in ZFS.

Another thing that is worth mentioning is swapcache mechanism in DragonflyBSD, as ZFS has its own caching mechanisms, swapcache is DragonflyBSD's mechanism to 'counter' that of ZFS.

You are very far off base on what Hammer's capabilities are. Most of what you stated is wrong, although dedup is a new feature for it. It also does some things much better than ZFS.
 
I'd be interested in HAMMER being an option for FreeBSD. I always figured it won't be an option due to politics. I haven't looked at Dragonfly since its initial release. I might have to give it a go again.
 
Galactic_Dominator said:
You are very far off base on what Hammer's capabilities are. Most of what you stated is wrong, although dedup is a new feature for it. It also does some things much better than ZFS.

Then quote all my statements and tell me where I am wrong, thats what I have read about HAMMER and I haven't been using it, so I MAY be wrong of course, saying only that I am wrong without ANY arguments is ... well, useless.
 
It would probably need to be using the GEOM framework instead of LVM. Dragonfly is based on 4.8 and GEOM was introduced in FreeBSD 5.0.
 
Thanks for some details. Why I asked about - ZFS v28 is last available version under open license. Next version come to close in Solaris. So as I understand it - is the end of the era of ZFS on FreeBSD?
 
pelmen said:
Thanks for some details. Why i asked about - ZFS v28 is last available version under open license. Next version come to close in Solaris. So as i understand it - is the end of the era of ZFS on FreeBSD?
Afaik the source is still open but will be released after solaris 11 is out. Right now only the preview is released (correct me if I'm wrong).
 
I think the answer is simpler than what is being tossed around: Someone took the effort to port ZFS to FreeBSD and continues to support it (pjd specifically). If someone did the same thing with Hammer, I don't think anyone would have a problem with it existing in FreeBSD. At this point, no one (that I'm aware of) has taken that effort and that's the reason Hammer has not been ported to FreeBSD.

Remember, there is not some central committee that's driving the development of FreeBSD. It's done by a loose confederation of developers. There was never a conscious decision on the part of the project to use ZFS over Hammer.
 
pelmen said:
Thanks for some details. Why I asked about - ZFS v28 is last available version under open license. Next version come to close in Solaris. So as I understand it - is the end of the era of ZFS on FreeBSD?
The features of ZFS as they were on FreeBSD 8.0 are groundbreaking. Jeff Bonwick declares ZFS as an "adult". It was pretty near feature complete as it was born. The most important features IMO are the ability to demonstrate that all your data is as it should be, and if a disk goes bad you can replace it and your data stays verifiably as it was. And also the snapshotting ability, since that allows you a means of recovering old and important stuff if it gets deleted either by accident or on purpose.

At the point where Solaris closes off the source, because of the Open Source license the FreeBSD devs are going to be able to fix bugs and add features if they should feel the need. The fact that ZFS as it is in FreeBSD is used in Oracle production systems should give an indication how production ready it is. And it's still way ahead of everything else. Over time the reliability will become (more) proven, while other competing filesystems won't have that advantage, and proven reliability should be one of your most important checkboxes when it comes to filesystems.

ZFS is a big drawcard for FreeBSD, so I can certainly imagine companies embracing FreeBSD and supporting developers to allow development to keep happening. If you want ZFS, you must choose FreeBSD, Illumos or Oracle. Illumos has nothing for release yet, and Oracle will make you pay for it.
 
"Having seen the writing on the wall some time ago, we started a coalition of several interested companies before OpenSolaris went EOL," Matt Olander CTO at iXsystems and a FreeBSD contributor, told InternetNews.com. "This coalition is invested in maintaining FreeBSD and ZFS technology. We are actively working together to make sure that ZFS has a very secure future on FreeBSD."
"It's my belief that in time, FreeBSD will become the de facto platform for ZFS as we already have all the pieces and don't have to maintain an operating system just to keep working on a filesystem," Olander said.
http://itmanagement.earthweb.com/os...-82-Expands-ZFS-Support----Without-Oracle.htm
 
Matty said:
Afaik the source is still open but will be released after solaris 11 is out. Right now only the preview is released (correct me if I'm wrong).

That's my understanding too of what Oracle have said, although Oracle can always change their mind :S
But as the code that is already open is always going to be open, ZFS on FreeBSD doesn't go away if Oracle stop releasing new code. It can stay as is or continue to be developed by the open source community in the absence of new code from Oracle.

Also re why ZFS and not Hammer, as Gordon says because someone decided to make the effort. Although I'd guess part of that decision, apart from technical features, may have been due to the fact that ZFS is coming from Solaris which is very well respected and widely used OS and ZFS was already a production FS. Where as Hammer is being developed by a very small community for an OS with a very small user base (I believe).

cheers Andy.
 
pelmen said:
Why I asked about - ZFS v28 is last available version under open license. Next version come to close in Solaris. So as I understand it - is the end of the era of ZFS on FreeBSD?
FreeBSD 8.2 Expands ZFS Support -- Without Oracle.
"Having seen the writing on the wall some time ago, we started a coalition of several interested companies before OpenSolaris went EOL," Matt Olander CTO at iXsystems and a FreeBSD contributor, told InternetNews.com. "This coalition is invested in maintaining FreeBSD and ZFS technology. We are actively working together to make sure that ZFS has a very secure future on FreeBSD."

Olander noted that besides iXsystems he was not at liberty to name the other companies, though he hinted that some of them are fairly large and successful. He added that he is also aware of other efforts to maintain OpenSolaris specifically for ZFS.

"It's my belief that in time, FreeBSD will become the de facto platform for ZFS as we already have all the pieces and don't have to maintain an operating system just to keep working on a filesystem," Olander said.
 
Nexenta has also committed to developing ZFS beyond what Oracle release(d|s) as open-source. GreenBytes also develops their own branch of ZFS, called ZFS+, based on the open-source releases.

Thus, even if Oracle never releases a single line of new ZFS code, ZFS will continue to be developed. Yes, maybe down the road "open" ZFS and "oracle" ZFS will diverge in their featureset. But there's why there's versioning. :)

Considering some of the other "open, then closed, so forked" projects (like OpenSSH, for example), there's really nothing to be afraid of here.
 
phoenix said:
Thus, even if Oracle never releases a single line of new ZFS code, ZFS will continue to be developed. Yes, maybe down the road "open" ZFS and "oracle" ZFS will diverge in their featureset. But there's why there's versioning. :)

Just guessing here, but this may act as a sort of driving force for Oracle to *not* close-source ZFS. If their and the OSS community's implementations diverge too greatly and become incompatible, there could be uncomfortable ambiguity in the name "ZFS". In order to keep things straight for IT professionals and thereby keep/grow market share, it's likely that the previous open source releases of ZFS will force Oracle to keep releasing ZFS code.

Long live ZFS! (If only because there are no english letters past "Z" and therefore no new file systems may be introduced. */sarcasm*)
 
AndyUKG said:
Also re why ZFS and not Hammer, as Gordon says because someone decided to make the effort. Although I'd guess part of that decision, apart from technical features, may have been due to the fact that ZFS is coming from Solaris which is very well respected and widely used OS and ZFS was already a production FS. Where as Hammer is being developed by a very small community for an OS with a very small user base (I believe).

Hammer was developed by computer scientist Matthew Dillon who developed for years on a well respected and widely used OS upwards a decade before creating a fork of that well respected and widely used OS do to commit privs being revoked against design philosophy and internal conflicts. You have a small straw man fallacy going on here.
 
UNIXgod said:
You have a small straw man fallacy going on here.

I don't think what I said was unfair, I wasnt trying to knock Hammar, or DragonFly or the developers (all of which may be technically very good). The main point was install base and number of people actively developing the FS, which I think is very much weighted towards ZFS.

cheers Andy.
 
gordon@ said:
I think the answer is simpler than what is being tossed around: Someone took the effort to port ZFS to FreeBSD and continues to support it (pjd specifically). If someone did the same thing with Hammer, I don't think anyone would have a problem with it existing in FreeBSD. At this point, no one (that I'm aware of) has taken that effort and that's the reason Hammer has not been ported to FreeBSD.

Remember, there is not some central committee that's driving the development of FreeBSD. It's done by a loose confederation of developers. There was never a conscious decision on the part of the project to use ZFS over Hammer.
The discussions I saw when that was being debated some time ago was more or less that ZFS was already in progress and that it was ultimately more important to focus on finishing it properly than supporting a million filesystems that are quasi-dependable. I don't recall reading anybody stating that they felt strongly enough about hammer that they'd do the port themselves. Which is ultimately a problem for those that want Hammer support.

Hammer does have good qualities, and I wouldn't be surprised to see support at some future date. But until somebody feels strongly enough about it to do the port, it's not going to happen.
 
Back
Top