Interesting article. So is the “unfriendliness” of Linux kernel developers towards ZFS that is mentioned strictly due to licensing issues or are there other points of contention?
You have a policy that you can't break users' programs, but borking their whole file-system is fine? Keep feeding end-users fears of open source petty feuds making people miserable. That works.
If ZFS wanted to live in userspace (and get Linux's userspace API guarantees) then they could have made a FUSE filesystem instead.
SPL now handles the guarantee to separate ZFS's userland components from Linux's constant internal kernelspace API churn. ZFS, internally, doesn't really know what a Linux is beyond a few little bits here and there.
I'll admit, I'm all talk and if it really mattered, pull requests are probably welcome.
These changes were made years later, but the developer of ZFS-FUSE disappeared, so they were never used.
The FUSE v3 API further builds on that, and today, it's definitely possible to build a high-performance filesystem using FUSE. In fact, there are many examples of this in the wild: GlusterFS, Ceph, NTFS-3G, and so on.
Today, there's absolutely _no_ reason ZFS would not sensibly work as high performance filesystem entirely from userspace. In fact, it still remains an open issue and a desirable target for ZoL: https://github.com/zfsonlinux/zfs/issues/8
End-user dont'care about splitting hairs. Iwas using Linux in the mid-90's and that kind of stance is what turned me off. The sound card would brek, the networking would break, configuring the modem would be hell after each upgrade.
The attitude that you must not break LibreOffice is not okey but breaking the file-system okay 'because it's a driver!' is just untenable.
Making people's computer fail will turn users away. It's not just a Linux thing. When Windows breaks stuff, all hell break loose on the Internet. The problem with OSS, is that its maintainers have no direct, immediate monetary incentive to amend. The long-term loss of confidence is hard to measure, but it's real.
Any reason why?
"My tolerance for ZFS is pretty non-existant" Greg Kroah-Hartman
"please switch to FreeBSD instead of advocating to violate the copyright and licensing rule on my and others work." Christoph Hellwig
But then why allow them?
I don't get it -- do they care more about what the users want, or about enforcing copyleft? If it's the latter, then they should be happy if those users who don't care about the GPL move to BSD. If it's the former then they should stop playing games and implement a fair policy for all non-GPL module authors.
Which is a shame, because it would have been nice to see if the shim usage pattern is actually a violation of the GPL - a lot of us would like a clear ruling there. I'm sympathetic to his viewpoint, but that whole ordeal was a bit of a "wtf?" because of how it was handled, and I can't imagine him being sympathetic to anything else in an even somewhat similar situation.
Its not non-GPL. Its non-GPl-compatible.
I can't even imagine the hassle of backporting stuff from much newer kernels into 3.10 to make btrfs work.
If you want to use btrfs in production (not the best idea, IMHO, but orgs such as facebook do it) you absolutely need to be running a 4.9.x or better kernel.
At the end of the day btrfs and ZFS both are just ways to help single-system administrators do better and more reliable backups. I know that's not how they're positioned, but really that's all they do.
ZFS on my laptop took me an evening to setup, but it's been completely hassle free. ZFS is really easy to use.
ZFS in particular seems to push more toward RAIDZ, whereas I'm a bit averse to striping in general nowadays for data recovery/reliability reasons (RAID1 + JBOD is dead-simple to recover, more flexible with heterogeneous disk sizes, and much easier to reason about IMO).
Having snapshots has saved me occasionally and find-new is really useful.
It might be a brilliant file system, but I'm never going ot use it because its such an arse to learn how to use it properly.
https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-about-b...
However, I often end up at the Arch Linux wiki, too:
BTRFS is basically on maintenance mode, and no one at Redhat/IBM or Ubuntu has any interest in keeping it alive. Anyone that requires HA services will not be using BTRFS.
Redhat ships with XFS as the default file system, Ubuntu ships with Ext4 as default with heavy install-time ZFS support for enterprise storage, and BTRFS is no longer being spoken of by anyone as a potential Ext5 candidate.
However, I'm pretty sure if I boiled the commit history down for the kernel, most of Facebook's commits would be Flashcache, and not BTRFS.
What I forgot, though, is SuSE supports it as their enterprise FS of choice, which is maybe more important than Facebook.
If you work some place that doesn't have that kind of luxury, perhaps a little extra conservatism is warranted before you go deploying across "millions of servers".
Btrfs is on maintenance mode? Based on what evidence? There's 1k-2k commits per kernel cycle. There are dozens of developers actively working on it. Facebook is certainly using it in production for high availability in concert with Gluster FS, they're also using Btrfs almost exclusively with Tupperware, their containerization service.
Red Hat has quite a lot of device mapper, LVM, and XFS developers so it makes sense for them to work on storage solutions that continue to build on that. And Red Hat hasn't been significantly contributing to Btrfs for many years now, so their lack of interest isn't new and hasn't affected Btrfs development.
You've never seen the same team working on two very separate code bases or products?
I have no idea if the btrfs and zfs teams at Oracle were merged, but I don't know that "they are two separate products" is actually a real argument that they weren't. Product teams working on separate things get merged all the time.
You can track developers through their git commits, and you'll see even when they change companies, they almost invariably keep working on the same filesystem they were before the move. Which is why the idea that Red Hat has no one working on Btrfs, means they want to see it go away is not what's going on at all. They have a lot of other developers already, who'd lose years becoming familiar with Btrfs (or ZFS for that matter). So you're going to see them build on what they already are familiar with, rather than moving laterally to a filesystem technology they're not familiar with.