FreeBSD and ZFS
freebsdfoundation.blogspot.com
freebsdfoundation.blogspot.com
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.
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).
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
My understanding is that Btrfs is still considered less stable than ZFS, or at least has been fairly recently.
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.)
With that in mind, let's see what the btrfs wiki has to say about the stability of btrfs:
"Is btrfs stable? Short answer: Maybe."
https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable....
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.
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.
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.
[0] https://softwarefreedom.org/resources/2016/linux-kernel-cddl...
(I hate it too, but that's no excuse to just ignore it.)
EDIT: Sorry, I accidentally downvoted you. Apologies.
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.
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.
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.
> 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)
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.
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 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?
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.
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).
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.
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.
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.
Type of Drives, did you have a L2 ARC and ZIL...
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
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.
[1] https://en.wikipedia.org/wiki/Adaptive_replacement_cache
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.
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
It's just that oracle is ever so much more likely to sue and actually win (see: the google api's are copyrightable case)
Neat, but the definitions I found say that's "harm without a legal wrong" (such as reducing someone's income by opening a competing shop).
To my untrained eye, the Linux kernel issue seems to be a legal wrong without harm, as you say ...