I don't really see how the code being CDDL is an "ugly" feature of ZFS when comparing file systems for use. What problem does that actually create for people who are looking for a file system to store their data on. Same for the point about Sun/Oracle. What issue does that actually cause for users of OpenZFS.



Do you have any examples of problems with AMD as well? A quick search didn't really turn anything obvious up, and both Intel and AMD processor use the same AMD64 version of FreeBSD, using the same code. So unless AMD processor have major bugs, I don't see why ZFS should have any specific problems on them.



I also don't really like the "ZFS needs ECC" arguments. ZFS needs ECC no more than any other file system. It's not like the developers specially made it rely on ECC features. With any file system, errors can happen in RAM which then get written to disk. Because one of the major ZFS "selling points" is that it has full data integrity, it's advised that users use ECC for production systems. Otherwise you run the risk of people thinking their data is 100% protected, when there is still actually a small chance of corruption. With other file systems no real guarantee of integrity is given in the first place. If HAMMER is supposed to provide great integrity, then I suspect ECC is advised there too.



Also I believe the OpenZFS project is fairly active. They've just had their developer summit and the original primary developer from Sun is still heavily involved. I think at the moment though the priority is more infrastructure work, building a solid API, making the code differences between ports smaller etc, stuff that doesn't really make any obvious changes for users.



I would like to see built in encryption, which does not exist at the moment. Can't see it happening any time soon though. The common way of doing it at the moment is with GELI, which is a lot more hassle than just using a dataset property like on Solaris.



It is also very complicated, there's not much chance of recovery if there is a problem, other than from backup. It does also seem to get slower over time as the data gets more and more fragmented. Makes scrubs slower as well as the scrub has to keep jumping around the disk to read the data in sequence. Not sure what the answer is for that other than rebuilding the pool every couple of years or so.



HAMMER seems intriguing but it still seems too new, hasn't had anywhere near the use and testing of ZFS so I'm not sure how much to trust it. It seems development has now moved onto v2, which has yet to appear, and has a very long list of desired features which worry me. Overall DragonFlyBSD just doesn't seem to have the user base or support for me to be happy using it for anything serious. And are there any sources to backup up the "phenomenal SQL performance" or it "beating the pants off everything else around"?