I honestly don't think Btrfs is ever going to take off.
We're better off just making a clean room implementation of ZFS, and just go with the better technical solution.
Meta, although morally bankrupt, _usually_ makes sane technical decisions. Backing Btrfs isn't one of them unless they plan on rewriting the whole thing from the ground up, and from what I've seen in the linked presentation, they're trying to rehab the worst data loss and performance bugs. They will never find them all.
> I honestly don't think Btrfs is ever going to take off.
Btrfs has taken off. It's the default filesystem for Fedora and openSUSE. It is being deployed at scale by billion-dollar enterprises. It is being used by a huge number of standalone NAS appliances, like those sold by Synology.
If anything, you should be asking "Is ZFS ever going to take off?". The licensing issues are clearly a massive hurdle, so a cleanroom reimplementation is essentially a hard requirement for it to ever catch on. So why aren't we seeing people actively working on one?
ZFS might have some technical details making it on paper better than Btrfs, but are its advantages enough to warrant an incredibly expensive full rewrite? Honestly, I doubt it.
ZFS already took off, though. The largest data pools in existence that are on an actual filesystem are on ZFS, nothing else can handle them. And it's only the kernel part that needs the rewrite, the userspace stuff is fine.
Btrfs was started as Oracle's gamble against Sun's ZFS, but then they just bought Sun, ZFS escaped to OpenZFS, and Oracle killed the Btrfs team entirely. Btrfs has never actually outgrown that decision. Oracle, ultimately, was their only meaningful corporate sponsor.
You mention Fedora, but ironically, RHEL had it as an alternative option and then removed it.
I'll take Btrfs more seriously when it can actually do what ZFS can, and I'm not even really using it to its fullest potential. It has no equivalent features to raid-z/z2/z3, and has no equivalent feature to l2arc and zil. It has compression, but lacks LZ4, and lacks early-abort heuristics for uncompressable data.
It seems like the main issue is BTRFS has some sharp edges: it's possible to use it in a solid way, but there's enough situations you can put it in where it completely fails that it's really hard to be confident deploying it unless you're really going to be very careful (and, to be fair, for all of ZFS's reputation, it also has a few sharp edges, but they seem to be more corner cases with certain combinations of features as opposed to pretty common use-cases. Heck, btrfs has had a corruption bug in the last two linux releases that's only just being fixed).
> The Linux Kernel is licensed under the GNU General Public License Version 2 (GPLv2). While both (OpenZFS and Linux Kernel) are free open source licenses they are restrictive licenses. The combination of them causes problems because it prevents using pieces of code exclusively available under one license with pieces of code exclusively available under the other in the same binary. In the case of the Linux Kernel, this prevents us from distributing OpenZFS as part of the Linux Kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code.
I think meta using btrfs is fine, their data isn't critical, heck I have never found a message of mine on facebook once its posted if the thread is above a certain size. At least now I can blame btrfs for the message's disappearance :-)
Yes, I'm aware. I use OpenZFS, and have so for almost a decade.
The kernel modules can never be merged into mainline due to license differences. The kernel modules would have to be reimplemented to change the license from CDDL to GPL. The userland tools, however, can stay CDDL.
Nice. This surely means they donated tens of millions to btrfs development.
Meta employs a number of engineers working on the Btrfs file-system
Maybe not tens of millions, but kernel fs engineers aren't exactly cheap either.
Darn. There is no discussion or elaboration on the specifics, just an offhand remark in an ongoing flamewar related to bcachefs :(
There's entire 40 minute video linked (I didn't watch it yet).
filler video
I honestly don't think Btrfs is ever going to take off.
We're better off just making a clean room implementation of ZFS, and just go with the better technical solution.
Meta, although morally bankrupt, _usually_ makes sane technical decisions. Backing Btrfs isn't one of them unless they plan on rewriting the whole thing from the ground up, and from what I've seen in the linked presentation, they're trying to rehab the worst data loss and performance bugs. They will never find them all.
> I honestly don't think Btrfs is ever going to take off.
Btrfs has taken off. It's the default filesystem for Fedora and openSUSE. It is being deployed at scale by billion-dollar enterprises. It is being used by a huge number of standalone NAS appliances, like those sold by Synology.
If anything, you should be asking "Is ZFS ever going to take off?". The licensing issues are clearly a massive hurdle, so a cleanroom reimplementation is essentially a hard requirement for it to ever catch on. So why aren't we seeing people actively working on one?
ZFS might have some technical details making it on paper better than Btrfs, but are its advantages enough to warrant an incredibly expensive full rewrite? Honestly, I doubt it.
ZFS already took off, though. The largest data pools in existence that are on an actual filesystem are on ZFS, nothing else can handle them. And it's only the kernel part that needs the rewrite, the userspace stuff is fine.
Btrfs was started as Oracle's gamble against Sun's ZFS, but then they just bought Sun, ZFS escaped to OpenZFS, and Oracle killed the Btrfs team entirely. Btrfs has never actually outgrown that decision. Oracle, ultimately, was their only meaningful corporate sponsor.
You mention Fedora, but ironically, RHEL had it as an alternative option and then removed it.
I'll take Btrfs more seriously when it can actually do what ZFS can, and I'm not even really using it to its fullest potential. It has no equivalent features to raid-z/z2/z3, and has no equivalent feature to l2arc and zil. It has compression, but lacks LZ4, and lacks early-abort heuristics for uncompressable data.
It seems like the main issue is BTRFS has some sharp edges: it's possible to use it in a solid way, but there's enough situations you can put it in where it completely fails that it's really hard to be confident deploying it unless you're really going to be very careful (and, to be fair, for all of ZFS's reputation, it also has a few sharp edges, but they seem to be more corner cases with certain combinations of features as opposed to pretty common use-cases. Heck, btrfs has had a corruption bug in the last two linux releases that's only just being fixed).
Regarding ZFS licensing…
> The Linux Kernel is licensed under the GNU General Public License Version 2 (GPLv2). While both (OpenZFS and Linux Kernel) are free open source licenses they are restrictive licenses. The combination of them causes problems because it prevents using pieces of code exclusively available under one license with pieces of code exclusively available under the other in the same binary. In the case of the Linux Kernel, this prevents us from distributing OpenZFS as part of the Linux Kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code.
https://openzfs.github.io/openzfs-docs/License.html
I think meta using btrfs is fine, their data isn't critical, heck I have never found a message of mine on facebook once its posted if the thread is above a certain size. At least now I can blame btrfs for the message's disappearance :-)
Now that is an interesting point.
No need to reimplement ZFS, it already supports Linux and several other operating systems.
https://openzfs.org/
Yes, I'm aware. I use OpenZFS, and have so for almost a decade.
The kernel modules can never be merged into mainline due to license differences. The kernel modules would have to be reimplemented to change the license from CDDL to GPL. The userland tools, however, can stay CDDL.