Yes, happily the ZFS license (CDDL) and (star)BSD licenses seem to be compatible. Yay for the BSDs of the world!
Unfortunately, most of the OSS/Free Software world is running a Linux kernel whose license (GPLv2) isn't compatible with the CDDL according to current thinking by most of the people who know about these things. End of story, AFAICT. (I mean there's a theoretical possibility of relicensing the Linux kernel, but given the contributor profile it's probably impossible in any practical sense. AFAICT it would be far more likely/practical for ZFS to be re-licensed under a GPL-compatible license if only the corporate overlords were so inclined.)
EDIT: Just a minor edit: I didn't mean that it's "unfortunate" that most of the OSS/Free Software world is running Linux. It works pretty damn well. My "unfortunately" remark was merely about the fact that licenses may be (or are) incompatible.
> Unfortunately, most of the OSS/Free Software world is running a Linux kernel whose license (GPLv2) isn't compatible with the CDDL according to current thinking by most of the people who know about these things.
This[0] is one of the more interesting reviews of this I've seen in a long time, including what seems like a footnote about dtrace at the end that I thought was a shocker.
Why must it be relicensed . Why not let it just be . Can the Linux people stop trying to tell everyone that everything needs to be gpl'ed or gpl compatible. It's like a 3 year old wining about how they can't get a second cookie .
Physician heal thyself. It would be optimal if this could be made more clearly gpl compatible as the current owner has a compelling interest in Linux as they now offer their own distro. That said nobody is whining just wishing.
In general, I think it would be most optimal if technical decisions didn't hinge on legal restrictions. GPL makes this less likely because of its absolutionist stance.
It's funny, but you're unintentionally perpetuating what's becoming the new stereotype. Now that the GPL has become mainstream, it's the anti-GPL people who come off as extreme. I'm not saying you're an extremist, but the GPL is not always the root of the problem.
In this case, it's a mutual incompatibility. This is just as much about the CDDL's restrictions as it is the GPL. The CDDL was created after the GPL, and it was an intended incompatibility. The GPL could have been the MIT license and the CDDL might have included a "cannot be distributed with MIT-licensed software" clause.
The point is that now that nobody has an interest in keeping ZFS out of Linux, it's time to relicense! That's all there is to it.
What about Turing and all the other guys that have done and still do great work? Should we end their careers because some of their work is secret? That's just un-australian.
Of course, you can't, which is why you're still following me months later posting impotent comments. I'm staggered how deep this bit, I really must have hit a nerve.
I work with a guy who has cddl'd his project . He likes the license ; I don't nag him to change it to an isc license . He has his reasons for the cddl, I might not agree with all of it but I am great full he open sourced it . If sun /oracle didn't open source zfs or dtrace we would be all be using Solaris and paying to use it . So if FreeBSD , NetBSD , illumos have a properly compatable licenses for zfs . Embrace that ; if you don't want to, check out dragonflybsd and hammerfs, look at btree on Linux , check out openbfs on haiku .
I can't stress this enough Canonical is a shitty company who needs to make waves to stay relevant . I don't know why anyone uses their crap . Wait I remember they are a commercial company with a marketing department who gets paid to polish that turd . What was so bad about Debian ? If you don't like Debian Why not give a a bsd a try . Hell why not just try Smart os and a lx-branded zone . You get zfs , dtrace , and all of the ful of full Linux comparability .
What are those reasons, concretely? Would he be better served by choosing e.g. a BSD variant? There's a non-trivial cost to choosing a "not-completely-understood" license. Or, equivalently, there's value in choosing a well-known "standard" license. While the CDDL should probably be classified as "well-known" at this point, its interaction with other licenses isn't, and -- unless you're actively working against GPL-ish licenses -- it's to be avoided. You can get what what you want by chosing a BSD-esque license instead.
I think I agree with many of your other points, though. As I say, I'm not a lawyer and not overly fond of licensing in the first place. (Still doesn't mean you can ignore this concern, unfortunately! If only ignorance of the law were an excuse!)
EDIT: If you're going to downvote, please explain. I don't care about the numbers, but I would like to know why my argument is wrong/misguided.
CDDL has nice properties. And really it's just an improvement on the MPL 1.0. There are good reasons to choose the CDDL (it's a file-based not work-based copyleft so the implications with stuff like linking are clear). It just really bothers me that we have licenses which restrict you from combining two works to create a new works that provides more guarantees of freedom than one of them. It's frustrating that by creating free software we now have different factions because we can't use other's free software.
The following answers were particularly applicable at the time Ubuntu came onto the scene.
> What was so bad about Debian ?
1) Unpredictable upgrade cycles. 2)Packages in stable were a bit on the ancient side. Ubuntu LTS is awesome (other projects like Firefox have since copied the fixed release cycle)
> If you don't like Debian Why not give a a bsd a try
Because BSD had (has?) poorer driver support for consumer products (like on my dev laptop)
I don't care much for Canonical and some of their other projects (Unity desktop, Ubuntu One), but Ubuntu as a project is pretty kick-ass. Ubuntu stepped into desktop linux in a big way as other Linux vendors abandoned ship (see RHEL)
How quickly we forget that Ubuntu tries to make things as user-friendly as possible. Debian does a decent job, but it's still rough around the edges in the desktop world. The BSDs aren't exactly friendly for non-techies either.
Frankly, you're an elitist, who doesn't care about the use-cases of anyone but technical experts. For most users, the type of filesystem in use does not matter, nor does access to dtrace.
Ha I am an elitist , your too funny; scroll back we are talking about zfs on hacker news; and I made a comment about how I dislike the work of canonical. To the point of making things user friendly; go get an Mac or Windows computer . Compare them to An Ubuntu install . Which is more user friendly? Is it Windows with its start menu and wizards , it's it OS X with its cool style and must have stuff , or is it Ubuntu with its polish of X11 and gnome . I don't know but my personal would probably say it's none of them .
Ah, I see. "X is a shitty company that needs to make waves to stay relevant" was a comment limited to merely the filesystem debate. Then, when it comes to user-friendliness, you abandon the bsds and other linux distros that you were talking about, shifting your goalposts neatly. But it does show your elitism again: user-friendliness should apparently stay away from the FOSS distros and remain the domain of windows/osx.
You were slagging off ubuntu and saying you don't know why people use their shit. I gave you a reason - in fact, ubuntu was responsible for a huge groundswell of interest in open source almost a decade ago, because of that user-friendly focus. That's a core part of why people use their stuff.
> it would be far more likely/practical for ZFS to be re-licensed under a GPL-compatible license if only the corporate overlords were so inclined.
I feel like that ship has sailed since there's Btrfs for Linux too - which also originated at Oracle.
I've always been curious why they kept working on Btrfs after acquiring Sun since they could've just relicensed ZFS to GPL/whatever.
Then again, I've also always been curious why people still keep glamoring over ZFS for Linux when Btrfs exists now, which, as far as I understand, is comparable to ZFS and a fresh implementation (for what that's worth).
Maybe it's just me, but I'm more than a little concerned by the fact that btrfs has been in development for over 8 years and still doesn't seem to be considered safe to use for storing anything I really care about.
ZFS has a considerable number of very useful features that Btrfs doesn't have. For example, under ZFS, you can delegate administration of a filesystem (subvolume in Btrfs terms) to a normal user. In doing so, you can, for example, set up each user's home directory as its own subvolume, allowing for per-account snapshots, and their own sets of subvolumes which can have differing properties as-needed. ZFS also has support in-driver for sharing volumes, which means nfs shares, and smb shares (unfortunately not under FreeBSD yet) work natively with the filesystem, and can be exported there, instead of needing to muck around with config files and then kicking things in the proper order.
Btrfs is still Not There Yet for a lot of the advantages ZFS has over traditional filesystems. It has a some, and some are half-baked, like its offline deduplication, but is still missing a considerable number. Maybe in five years Btrfs will catch up, but it's not here now.
Rearding licensing, the Linux kernel devs could also relicense to allow for cddl co-existence. Unfortunately, the petulance from such groups as the SFLC makes that very unlikely.
the ZFS commands are more logical, and better designed
The ZFS FileSystem is truely enterprise ready... btrfs is atleast 5 years away from being production ready
btrfs has all kinds of bugs and issues.
zfs did not hold to legacy conventions, they looked at filesystems in a differnet way.
btrfs attempts to hold on the traditional filesystem methodology and shoehorn more modern ideas in to that traditional framework, and IMO it does not work at all
the zfs and zpool commands are brilliant, intuitive, and easy to use.
The btrfs command structure is complicated, non-intuitive, and antiquated
It is comparable in that they are both filesystems... Supposedly the situation has been improving but at least as of months ago compared to zfs performance was horrible, features were lacking, and likelihood of data loss was a lot higher.
> Then again, I've also always been curious why people still keep glamoring over ZFS for Linux when Btrfs exists now, which, as far as I understand, is comparable to ZFS and a fresh implementation (for what that's worth).
My understanding is that Btrfs is still considered less stable than ZFS, or at least has been fairly recently.
> I feel like that ship has sailed since there's Btrfs for Linux too - which also originated at Oracle.
Unfortunately, I think you may be right. It's just sad -- because probably nobody who's anyone at Oracle cares and/or understands.
> Then again, I've also always been curious why people still keep glamoring over ZFS for Linux when Btrfs exists now, which, as far as I understand, is comparable to ZFS and a fresh implementation (for what that's worth).
It is mostly comparable feature-wise, it's just that it hasn't achieved anywhere near the same level of stability for anything other than single-device usage. (At least that's my understanding from following the mailing list for years and years.)
A while back I was considering Freenas and in the documentation/forums I read dire warnings about running ZFS with less than 8 gigabyte of ram. Apparently, this could actually put your data at risk.
I was a bit nonplussed by this. The least I would expect from a file system is that it degrades gracefully. I wonder if anyone knows more about this?
FreeNAS people seem to mix up what's recommended vs what's required.
The whole myth that ZFS requires ECC memory comes from them, but in reality ECC is as much helpful with ZFS as with any other FS. It's not that ZFS will start destroying your data if you don't have ECC. It's just that ZFS provides guarantees, but it can't help much if data is corrupted in memory, but any other filesystem will also be affected in that scenario.
Similarly with 8GB. You can actually run ZFS on 1GB, but the more RAM you have the better. ZFS has ARC (Adaptive Replacement Cache[1]) which speeds up read access by storing in RAM most frequently accessed data.
Not running ARC won't affect safety of your data, it's just that you'll get worse performance.
There are some warts ZFS (and most likely COW file systems) have. For example until ZFS will have a defragmenting tool (doesn't looks like anyone is working on it) you don't want ever to use more than 80% of your disk. If you do, you'll permanently reduce performance of the pool and currently the only fix would be to backup all the data, wipe disk and restore it (this effectively will defragment it).
Another issue is that deduplication in ZFS is essentially useless. It requires obscene amount of RAM to be used, and if you enable it with less, it'll drastically reduce performance as well. Instead of deduplication it's better to just enable compression.
FreeNAS do seem to recommend ludicrous minimum amounts of RAM, even without dedupe. If you ferret around their forums there seems to have been some history of data loss on low RAM machines. I don't know if it's something they've introduced but I've not seen mention of similar issues around the FreeBSD forums.
If you compare with the FreeBSD guide to tuning ZFS, they recommend 1GB and up and give settings for tuning for 768 MB. They mention that in practice dedupe would like upto 5GB / TB, so I've never bothered. 99 out of 100 don't need dedupe anyway - compression will be better.
I've never had an issue running FreeBSD + ZFS on a 1GB machine, which was my file server for several years. I ran FreeNAS with 1GB for around a year without issue. I'm now running a HP microserver with 16GB which gives 12GB to ARC.
I've been running ZFS on a machine with 768 MB of RAM and there have been no issues.
If you set the size of the ARC cache according to your needs and you do not use deduplication then you won't encounter any issues. Deduplication requires a giant hash table and is rarely beneficial.
I run FreeBSD with ZFS on the home server, which primary purpose is storing and processing video files from two surveillance cameras.
ZFS pool is created as RAID-1 array of two 2TB HDDs. Server has 2GB DDR2 RAM, but ZFS in-memory cache is restricted to 512MB. OS architecture is x64. ZFS deduplication is turned off. CPU is Intel Atom D510. Not very fast, but it was chosen for low power consumption considering special case when grid power goes off and whole system (including server, cameras and PoE switch) runs from backup DC batteries.
I've never had any problems with this setup during 3+ years. It's rock solid and even has extra CPU time to run motion detection software and Transmission (BitTorrent client).
I would have to see proof that is was low ram that caused the data loss.
The Recommendations for higher amounts memory comes from the way ZFS Caching works. There are 2 caches, ARC and L2-ARC. L2-ARC has to be defined on a SSD and is optional. ARC will always exist and ZFS will use every bit of free memory you have (unless you change the configuration to limit it) to build the cache.. why ram is faster that is why.
So the only scenario I could conceive of that would result in data loss is if you are writing files to the ARC faster than ZFS can commit them to disk but that seems unlikely and ZFS should not allow this anyway.
for Enterprise work loads the Recommend amount of Memory is 1GB per TB of storage. This is for best performance, however my home server is 35TB and ran for about 2 years with 8GB, and recently upgraded the system to a new proc, mainboard and 16gb a memory, have had no issues with either. I have about 2-3 Movies streaming from it with about 3-4 devices/computers connected for network file storage.
The more RAM you give ZFS the better performance you get (to a point) but I believe this issue is massively over talked about and hyped.
> The more RAM you give ZFS the better performance you get (to a point) but I believe this issue is massively over talked about and hyped.
Definitely not hyped as you said in the enterprise space - think some home users see that warning of 1GB per 1TB though and get put off.
In my experience we were running multiple vSphere NFS volumes on several large 16x bay FreeNAS systems. We started with 16x 1TB disks and 16GB of RAM. It wasn't until we installed 32GB of RAM before performance became acceptable. Ideally we should really have put in 64GB of RAM but alas Intel's damn Ivy Bridge E3 range maxed out at 32GB.
I should stress we were only running 20 virtual machines in total so nothing massively onerous, but that extra RAM made all the difference.
There are alot of reasons why you may have needed the additional ram. If you were using off the Shelf 7200 (or worse 5400) NAS drives then I am not shocked, these drives are for storage not for VM's. need atleast 10K drives for VM storage
>Definitely not hyped as you said in the enterprise space - think some home users see that warning of 1GB per 1TB though and get put off.
It still kinda is, but 90% of the questions I see posted in various places are about Home and Test Labs, not Enterprise Deployments.
you do not need 32GB of RAM for your home file server that is likely serving less than 10 clients.
ARC actually is optional, and in fact FreeBSD disables it by default if you have less than 2GB RAM.
1GB per TB or more like 5GB per TB is rule of thumb if you use deduplication. If you don't use deduplication it's more of: "the more RAM you have the better performance you get for reading"
ARC is not for writing. It's purely used for improving read performance. For improving write performance you use ZIL device. ZIL is essentially a journal. If you don't specify ZIL device ZFS will store it on data disks. If writing performance is important it is recommended to keep ZIL on separate device (especially SLC SSD). More about ZIL: http://nex7.blogspot.com/2013/04/zfs-intent-log.html
There's no need for BSD to comment on their "longstanding relationship" with ZFS if they're only saying "we have it and it works within our framework" versus adding something constructive to the dialog on its licensing in Linux. It's awesome that the BSD and ZFS licenses are compatible and that it works well. It just has nothing to do with the headlines they are addressing.
No, the FreeBSD foundation is showing that different entities, with different licenses, can cooperate. As the SFLC mentioned in their original posting, combining ZFS in the kernel feels little more than damnum absque injuria. In order for any judgement to be laid, there has to be shown some sort of injured party. Who is injured exactly by integrating a kernel module with primarily CDDL code with the Linux kernel, which itself already includes many binary only files where the licensing is questionable?
> Who is injured exactly by integrating a kernel module with primarily CDDL code with the Linux kernel
Oracle as the sole copyright holder of zfs might be because thy lose potential Solaris sales when zfs is distributed with Linux this way. At least they could argue that before some court
There still are a lot of lines in a lot of files that were written by Sun employees which are now owned by Oracle. So the same way a kernel developer has a potential standing to sue canonical over their potential GPL violation, Oracle has the same potential standing to sue canonical over their potential CDDL violation.
It's just that oracle is ever so much more likely to sue and actually win (see: the google api's are copyrightable case)
Unfortunately, most of the OSS/Free Software world is running a Linux kernel whose license (GPLv2) isn't compatible with the CDDL according to current thinking by most of the people who know about these things. End of story, AFAICT. (I mean there's a theoretical possibility of relicensing the Linux kernel, but given the contributor profile it's probably impossible in any practical sense. AFAICT it would be far more likely/practical for ZFS to be re-licensed under a GPL-compatible license if only the corporate overlords were so inclined.)
EDIT: Just a minor edit: I didn't mean that it's "unfortunate" that most of the OSS/Free Software world is running Linux. It works pretty damn well. My "unfortunately" remark was merely about the fact that licenses may be (or are) incompatible.