ZFS support on macOS has been barely beta-quality for at least five years. I wish it were actually cross-platform, but it really only works well on Linux and FreeBSD.
I've tried 4 or 5 times over the last 3 or 5 years to use it on macOS and I've been rewarded with hangs, corruption, kernel panics. For something as critical as a filesystem, it's just not ready.
how is it possible that something created by basically one dude in his spare time on windows is working well when there are dozens of developers trying to implement it correctly in the linux kernel?
or perhaps my impression after this recommendation is wrong and this actually isn't working well?
> how is it possible that something created by basically one dude in his spare time on windows is working well when there are dozens of developers trying to implement it correctly in the linux kernel?
I don't think there is any case where this WinBTRFS would work better than the Linux implementation, but the Linux implementation is solid enough - if BTRFS is good enough for Synology NASes (https://www.synology.com/en-global/dsm/Btrfs), it's good enough for me.
I wonder what led you to this line of thinking though. It reminds me of people being amazed at $NEWER_TECH just because it had less time to accumulate bug reports.
I think Ubuntu adoption of ZFS is a testament that it is here to stay. Btrfs still has some issues (eg stability), which ZFS simply doesn’t have. It’s rock solid.
Fedora is going to BTRFS. I guess that means it is being at least considered for RHEL 9 or 10. I can't see RH choosing ZFS unless the license is sorted out.
I have no relation to either Fedora or RH, but have gone through quite a bit of their mailing lists in the past few months. Fedora adopting btrfs has nothing to do with RHEL and they don't seem to be considering it at all. Red Hat threw all their weight behind XFS with advanced features being added mostly through separate layers (e.g. stratis).
I also have no relationship to RH other than as a user of their free stuff.
Yes when it became apparent that BTRFS was not ready RH did that. It was a slight surprise when it happened if I remember correctly.
I said RHEL v9 OR 10. I guess 9 is unlikely but 10 is a number of years off. If BTFS is a sucess on Fedora and stable then they will surely consider it. That is the point of Fedora...
I work for Red Hat but have no insight into any of the Stratis/Btrfs/etc stuff. I'm just a long time Fedora user.
I would agree with you. Fedora adopting stuff does not mean RHEL will include it, but if it's successful/popular on Fedora then Red Hat will surely be paying attention. RHEL tries to follow Fedora as closely as possible, I would imagine this is a shot for btrfs, but certainly no guarantee.
Red Hat previously added btrfs to RHEL as a "Technology Preview", only to later remove it (they didn't really have anyone left devoting resources to it, IIRC), deciding to focus on stratis / VDO instead [0]. They do have several XFS folks, though (or did, last I knew).
FWIW, SUSE is the Enterprise Linux vendor that has went "all in" on btrfs.
---
Two semi-related, personal thoughts:
1. btrfs today feels a lot like reiserfs did (going on / nearly) 20 years ago.
2. I expect Oracle to -- at some point -- integrate ZFS into Oracle (Enterprise) Linux. That seems like a great way for them to win over some "converts" from RHEL.
Oracle owns ZFS. Or, rather, it bought Sun, which was the company which originally wrote ZFS. So, it doesn't really need to worry about the licensing issues.
@AlgorithmicTime you've been shadow banned it seems but you did raise a point that is worth expanding on:
> Oracle owns ZFS. Or, rather, it bought Sun, which was the company which originally wrote ZFS. So, it doesn't really need to worry about the licensing issues.
Oracle owning ZFS doesn't magically absolve them of risk however it does reduce the risk. But with ZFS being open source, another contributor might have a claim if Oracle were to breach the CDDL license with code written by said contributor (similar to the SCO vs UNIX lawsuits of yesteryear).
To get around this Oracle would need to contact all 3rd party contributors and get the to agree to a license change. This would, in all practicality, then be reflected in a new release (like the GP suggested).
However it is now even more complicated than that because OpenZFS (which is what Linux runs) has diverged from ZFS (which Oracle maintain). So while Oracle would need to agree to any changes in the licensing of OpenZFS (as there's still Oracle code present in OpenZFS), Oracle are not the ones maintaining it and nor could they ship their own version of ZFS as Linux kernel modules to answer any concerns with either OpenZFS licensing nor compatibility with other Linuxes running OpenZFS.
One assumes that if Oracle decided to do its ZFS on Linux, it would do so under an actual compatible license. Since Oracle owns Oracle's ZFS, they can just release it under GPLv2 (or MIT, BSD, whatever) and not be even potentially doing anything that would let someone sue them.
There is no "just" in "just release it under [another license]". I'd written a detailed rebuttal of why it's not that simple in the GP post to yours: https://news.ycombinator.com/item?id=24331156
I did forget the amount of effort to port OracleZFS to work with Linux, true, but I stand by the claim that they could release their own ZFS code under any license they want. They wouldn't have to "contact all 3rd party contributors and get the to agree to a license change", because Sun only took code that was legally signed over to them. The resulting OracleZFS would be missing all OpenZFS code (because indeed that code would only be available under the CDDL), but insofar as that it was missing code that Oracle didn't own it could be licensed at will. This would leave them having to invest the effort to port OracleZFS to run in Linux, which is a valid argument against them taking this approach.
Oracle maintains it's own version of ZFS, which has been separate from OpenZFS since Oracle bought Sun. There us no "Oracle code" in OpenZFS, though some of the patents on techniques are owned by Oracle.
If Oracle wanted to ship ZFS on Linux, they would presumably port over their own version and never involve the OpenZFS team. However, Oracle created btrfs, and seem content to stick with it.
> Oracle maintains it's own version of ZFS, which has been separate from OpenZFS since Oracle bought Sun. There us no "Oracle code" in OpenZFS, though some of the patents on techniques are owned by Oracle.
OpenZFS is a fork of ZFS rather than a reimplementation so I'd be very surprised if there wasn't any Oracle code in it (unless you're making a distinction between Sun and Oracle but legally speaking that would all still be owned by Oracle, hence why I didn't make that same distinction myself).
> If Oracle wanted to ship ZFS on Linux, they would presumably port over their own version and never involve the OpenZFS team.
Porting in this case isn't a simple task as there's a lot of "Solarisims" in ZFS that had to be worked around with the Linux port (ZoL -- ZFS on Linux -- didn't happen over night). Plus, and as I'd said earlier, ZFS and OpenZFS have diverged in terms of supported features so a ZFS volume wouldn't be compatible with an OpenZFS volume. I guess this wouldn't bother Oracle since, like most orgs of that size, they have no qualms with creating vendor lock ins. But it certainly wouldn't do much to sell Oracle Linux to the wider ZoL community.
>but legally speaking that would all still be owned by Oracle, hence why I didn't make that same distinction myself)..
The reason the distinction is important is that Sun released that code under the CDDL. If Oracle wanted to somehow claim it couldn't be used, it would require a massive lawsuit that would basically be against the concept of free software.
> The reason the distinction is important is that Sun released that code under the CDDL. If Oracle wanted to somehow claim it couldn't be used, it would require a massive lawsuit that would basically be against the concept of free software.
I don't understand why that would be necessary. CDDL (and equivalent) licenses don't transfer ownership of IP (intellectual property) to the public domain, they only outline usage and distribution of the code and compiled artefacts. When Oracle bought Sun, they acquired Sun's IP (amongst other things) -- hence why they could go after Google with regards to their Java IP despite Java being a Sun Microsystems creation. ZFS isn't any different, it might have been distributed under a CDDL license but since Oracle now own the copyright for ZFS code they can legally re-license that code base under another license if they wished. So Sun doesn't factor into the equation any more since what was Sun's is now owned by Oracle.
It's worth noting that you do occasionally see open source projects change their software license years after their initial release. So this isn't an untested theory.
I'm saying that Oracle couldn't retract the releases already released under a free license, getting rid of OpenZFS altogether. They can and have relicensed the codebase, but we can just pull from the last version released under the CDDL.
From my understanding of open source projects released under a new license, they often can create a similar fork at the license change time where a version exists under the old license too. The exception is if they use the GPL version that allows updating the license
> I'm saying that Oracle couldn't retract the releases already released under a free license
Nobody is suggesting they retract older version. In fact the exact opposite has been said on multiple occasions: any new license would be signified by a semver (semantic version) bump. So you're arguing against a point that was never made in the first place.
> getting rid of OpenZFS altogether
OpenZFS code would be unaffected because it's forked from a version prior to the semver re-license bump.
> From my understanding of open source projects released under a new license, they often can create a similar fork at the license change time where a version exists under the old license too.
Fork or semver bump. Which is exactly what I was talking about. Also notice that what you described there contradicts what you said would happen ("getting rid of OpenZFS") in literally the same comment.
---
If Oracle own the copyright then Oracle can re-license. They'd have to bump the version number and the previous versions with the older license would forever remain CDDL. But legally they can do it and it wouldn't affect OpenZFS licensing (aside that OpenZFS might then no longer be able to incorporate ZFS code -- assuming ZFS's new license is incompatible with CDDL. But things start to get very murky down that road.)
>Also notice that what you described there contradicts what you said would happen ("getting rid of OpenZFS") in literally the same comment
My argument has been that Oracle can't do this the entire time, but that's why its unfair to say there is Oracle code in OpenZFS. It makes it sound like Oracle has some power over OpenZFS, which is just not the case.
> My argument has been that Oracle can't do this the entire time
No it wasn't. You kept bringing Sun Microsystems into the discussion and they're not relevant regardless of whether we're discussing ZFS or OpenZFS because Oracle own Suns IP. Moreover, and I can't stress this enough, nobody ever suggested OpenZFS would be "got rid of" except for yourself! You created that straw man argument.
> that's why its unfair to say there is Oracle code in OpenZFS. It makes it sound like Oracle has some power over OpenZFS, which is just not the case.
It's not unfair to say that because that is the literal truth. And I was very clear about not only the distinction between ZFS and OpenZFS but also the limited scope in which Oracle could control OpenZFS (if the OpenZFS guys want to re-license they'd still need Oracle's approval for any Sun IP (which Oracle now own) that remains within OpenZFS code).
Claiming that Oracle code doesn't exist within OpenZFS or that Oracle doesn't still have a say with regards to OpenZFS's licence would be as ignorant as saying Oracle could "get rid of OpenZFS".
I suggest re-reading my initial comment that sparked this discussion. I thought it was pretty clear about the distinction between ZFS and OpenZFS and about how much/little control Oracle have over the licenses of each.
All that aside, one comment you made elsewhere did interest me: whether Oracle could sue Canonical due to copyright grounds with Oracle code in Linux. I don't know GPL well enough to know if this is possible but it's a truly terrifying thought given the amount of contributors to Linux and the prevalence of Linux in propitiatory systems like phones, routers and other places that might contain closed SoC modules.
Redhat has a problem that Fedora doesn't have: they stick to a kernel version through the entire release life cycle. In other words, they are stuck with a specific kernel for at least 10 years.
Btrfs goes though a rapid development; so Redhat has to backport everything to their ancient 3.10 (RHEL7) kernel all the time. That's a lot of work.
Fedora, on the other hand, uses current kernels. They do not have to do this work.
Redhat also cannot choose ZFS while in the license limbo; that's why they push for Stratis.
Also, do these Debian cautionary notes still apply to new code:
> There is currently (2019-07-07, linux ≤ 5.1.16) a bug that causes a two-disk raid1 profile to forever become read-only the second time it is mounted in a degraded state
Don't use RAID5/6 in production. This is well-documented , and the remaining issue (the write hole) is being worked on. As with any software, don't use features not marked stable in production.
As for the write-only bug, 1) that only affects 2-disk RAID1 setups where people insist on cowboying around with their degraded arrays, and 2) doesn't result in data loss, merely an additional copy step to restore the array. Don't run your arrays in a degraded state, please.
As I wrote, SUSE considers Btrfs stable for production use, and they're the premier enterprise distro in Europe.
> Don't run your arrays in a degraded state, please.
That's easy to say, but if you get a bad disk in a mirror on your boot drives, and for some reason your system restarts during this time period, you boot up into read-only mode--which kind of keeps your server down and kills service availability.
I don't run Btrfs, and so heard about this scenario from Jim Salter (the author of the linked Ars article) in his podcast:
> I think Ubuntu adoption of ZFS is a testament that it is here to stay.
Like Mir, Unity, Upstart and all the other technologies Ubuntu adopted, but removed after a while again? I always have the feeling that the Canonical engineers try to advance the Linux ecosystem by introducing new technologies, but somehow always pick the wrong ones, which end up not being adopted anywhere else. Granted that's different with ZFS, as ZFS already has a large user base, but there is nothing guaranteeing that Ubuntu won't remove ZFS in a few years again.
The other projects were (for the most part) anonical originals" that they tried to create -- primarily on their own -- to replace existing products. ZFS is going on 15 years old, quite mature, highly trusted, and, of course, it already has a huge existing userbase.
It's certainly not an internal Canonical project that requires them to devote huge teams of developers to it. Unlike the others you mentioned, ZFS will continue to exist and grow regardless of Canonical's involvement.
ZFS isn't maintained by Canonical and has a massive user base outside of Ubuntu. It is not a passing fad and even if Ubuntu did drop official support people could still compile it themselves (like I do).
> ZFS is great but aren't we better off focusing on something else like btrfs?
Btrfs was originally introduced in Linux 2.6.29 in March 2009. It is still flakey in many situations.
ZFS was first release in Solaris 10 6/06 in June 2006, with it being open source almost right away. OpenZFS was forked in August 2010.
Should Btrfs at some point simply be declared a sunk cost and something new be created? Because from the outside it looks like it's hardly gaining any traction because of its reputation for eating data (maybe only with its RAID code, but still).
btrfs was removed from RHEL because RedHat themselves don't have the time or energy to support it or support systems using it. That's going to hurt adoption. Ubuntu is working actively towards ZFS as an available/default option, and once it is there's not much point in using btrfs unless you have specific use cases. Everyone else I know either uses ZFS or XFS in production. For my systems, I would definitely not trust btrfs with critical data.
Here's the thing: btrfs is 'fine', but it's not 'good'. It's the only filesystem since 2001 where I've suffered unrecoverable filesystem corruption as a result of a power outage (on a fresh 18.04 installation last November) and had to salvage data and reinstall.
The tooling, in a lot of cases, does the opposite of ZFS and touts it as a feature. For example, snapshots are not recursive and they say that this is great for if you want to snapshot / but not /home; this is true, but it also means that I cannot subdivide datasets.
For example, on ZFS I divide up /var/lib/mysql/ into /var/lib/mysql/tablespace/ and var/lib/mysql/logdb, for example, since both of those have different access patterns and block sizes (16k and 128k respectively). ZFS lets me do this to optimize reads and writes, but I can also atomically snapshot them both. btrfs doesn't let me do an atomic, recursive snapshot at all (and I'm not sure if it can handle different block sizes per subvolume either).
Basically, ZFS is a better, production-ready, enterprise-proven, and surprisingly intuitive filesystem and volume management system, and has been for 14 years. btrfs has weird tooling, incomplete features (which they don't just remove from the roadmap for some reason), data loss issues, and the only large-scale use I've heard of it Facebook, who also work on it (easier to use btrfs when you've hired all the experts).
With Ubuntu shipping ZFS enabled by default, most reasons to use btrfs go away; it's not mainlined in the kernel, but that doesn't matter if your distribution has it enabled and supported by default.
Btrfs came in time, when RAID5 was "declared obsolete"[1]. All its users are focused on single/striped/mirrored functionality, and almost nobody is interested in (paying for development of) parity functionality.
That's why btrfs RAID5/6 mode is in the sorry state it is. Nobody capable of paying the piper is interested in it. It is a domain of datahoarders, but that's not where the money is. Even Synology has put btrfs on top of mdraid for that.
Outside the parity modes, btrfs is stable and reliable. It is here to stay.
So why not simply remove raid 5/6 and solve the last few things on the roadmap. Being stable and seen as save by most people is much more important than having some features almost nobody is using in production.
Why does it bother you that raid5/6 is there? Just do not use it, the end result for you and most people is the same as if it was removed. For those few who want to play with it, it is still there. Best of both worlds.
I don't think this deserves the down votes. I love ZFS, use ZFS and I'd still say that the licensing issue is real. Just because Oracle hasn't sued Canonical doesn't mean they can't or won't.
Please excuse the ignorant question, but what grounds would Oracle have to sue Canonical?
OpenZFS is still open source and available on FreeBSD (amongst others). The licence might not be GPL compatible but the way ZFS is shipped on Linux there isn't any GPL/CDDL mixed code bases (and it's not like there isn't already a long history of GPL-incompatible software licences with Linux kernel modules anyway).
IIRC, The GPL incompatibility prohibits distribution of linked binaries. Since the CDDL-licensed ZFS kernel modules have to be linked against the kernel, those compiled modules can't be distributed.
Hence, Canonical (or anyone else trying to re-release under the CDDL) cannot distribute binaries of the kernel modules.
However, you are fully allowed to compile and link the two on your own. This is why the alternative to binary distribution is compiling yourself with the help of DKMS.
With the two licenses incompatibility, the GPL is the one that would be violated, not the CDDL. So any Linux contributor would have the right to sue, including Oracle who presumably have committed to Linux. However, Oracle owning ZFS gives them no extra grounds to sue over OpenZFS.
"The way it is shipped" differs by distro and the message by non-ubuntu distros is that the way ubuntu ships zfs seems legally risky to them. Ubuntu disagrees and they might be right (isle of man jurisdiction IIRC?), but their legal theory has not been tested and oracle has a reputation.
This was my takeaway as well. Which is why I was puzzled by the comments about Oracle suing Canonical.
That said, boomboomsubban (https://news.ycombinator.com/item?id=24331590) suggested Oracle could sue on the GPL side of things since they have committed code to Linux. It would be interesting if such a position is possible and I suspect that could open the door to all sorts of frivolousness cases (eg closed binaries shipped with Android).
BTRFS at this point feels a lot like a sunk cost fallacy - it proved its unreliability too many times over the years, and working on it feels like throwing good money after bad.
Understandably some people may be more interested in not losing their data than the licensing headaches it may come with, so ZFS it is.
Some, like yours truly, run FreeBSD on their NAS, where there are no license issues either, and are very happy it rebased on OpenZFS recently.
> it proved its unreliability too many times over the years, and working on it feels like throwing good money after bad.
Btrfs has been working fine for years and is used largely at Facebook. RAID 5 and RAID 6 are still unstable (and marked as such) but the rest just works.
> Btrfs has been working fine for years and is used largely at Facebook. RAID 5 and RAID 6 are still unstable (and marked as such) but the rest just works.
I get the feeling that if you are a ZFS user then RAID 5 & 6 not working is just a deal breaker.
> [most potential users, including] home NAS users, have at most two HDD.
Let's not truncate this sentence to avoid altering its meaning. I certainly don't deny four drives NAS exist but I think dual bays are still a lot more common.
Anecdotally I know a lot of people with one drive NAS (some ISP provide them here), a few people with two drives NAS (including me) and no one with four drives (but I don't know anyone heavily into photography or video which seem to be the main usage).
My point was that you can still address a large segment of the home users market without RAID 5 and RAID 6.
It doesn't "just work". There are multiple significant design defects which result in absolutely atrocious performance in many common scenarios, or even stop the file system from working. These haven't been addressed.
The RAID5/6 issues are significant, but don't pretend that Btrfs would be OK if these problems were resolved. There are still many others waiting to be fixed as well.
Please list their supposed "multiple significant design defects which result in absolutely atrocious performance in many common scenarios", and explain why you think they are not inherent to CoW filesystems in general.
Likewise. Not even using RAID 5 or 6, just RAID 1. Completely destroyed all the data on both mirrors. Truly terrible. When the error codepaths are this poorly tested, it does not inspire confidence.
I believe the bug which caused this is now fixed, but who really knows what other nasties linger on waiting to be triggered.
In comparison, ZFS has been a dream. I even moved terabytes of data between a Linux system and a FreeBSD server simply by swapping the discs over and running "zpool import". Superb data portability.
Oh thank god there's a way to disable autosnapshot! It's been filling my drive with useless snapshots ever since I installed Ubuntu with zfs support, drowning out my real snapshots. Who needs a snapshot after calling "apt install htop" anyway? The ZFS snapshot and grub update processes increase the install time 3-fold, and run the risk of seriously hooping the system if the power goes out unexpectedly.
Has anyone had any real problems with apt install or apt remove busting their systems? Seems more like a solution in search of a problem.
Problems due to apt operations should be pretty rare, but even uncommon events can be worth de-risking. The value in providing this kind of feature is:
* For expert users who have hosed a system -- particularly if it happens to be a production host -- there's an immediate sense of relief and ability to rollback safely, confidently and quickly.
* For less-experienced users who run into problems, there is a convenient and straightforward way for their technical support to explain to them how they can restore their system to a previous state.
Since hosts and their installed packages have varying hardware and configuration states and update/maintenance schedules, incompatibilities and breaking changes are likely to occur occasionally and that's where snapshots can help.
> Who needs a snapshot after calling “apt install htop” anyway?
I’d think the more useful feature would be taking a snapshot at the beginning of the apt run; and then tossing it away if apt manages to complete successfully. That way, apt returning a nonzero exit status could be caught by a wrapper script, that would then transactionally revert the changes.
I believe NTFS still does this for Windows updates, even if “transactional filesystem” features are no longer “available” (i.e. exposed to userland.)
Of course, unlike NTFS’s filesystem transactions, ZFS snapshots aren’t MVCC — you can’t have multiple parallel ones going on at once that get merged on success. So that apt-wrapper-script reverting, might throw away something else you’ve done to your rootfs (and hopefully only your rootfs; such a technique would effectively require moving all user-mutable data to other mounted volumes.)
Apt completing successfully is not the same thing as the installation completing successfully. For example, Apt could successfully update a bunch of libraries, versions, etc. which now breaks your application, but because apt's actual tasks succeeded the snapshot gets removed and now you can't roll back.
> and hopefully only your rootfs; such a technique would effectively require moving all user-mutable data to other mounted volumes
I believe that zfs installation creates a separate dataset for /home, meaning that it won't be rolled back along with everything else. The same should be true for things like /var/lib/, but I haven't done such an install in a while, since the first 20.04 build with zfs enabled.
> The ZFS snapshot and grub update processes increase the install time 3-fold
Creating ZFS snapshots is almost instantaneous due to the CoW nature of the filesystem. Is it deleting old snapshots during that process? If so, I'd suggest checking to make sure you have the async_destroy feature enabled for your pool.
If anyone is wondering about the historical context to this, look up "boot environments", which first appeared under Solaris with FreeBSD copying the feature:
I've been updating my freebsd-current desktops for quite a few years with beinstall / beadm, and I love it. The ability to quickly roll back from an update is critical on a rolling-release OS like freebsd.
90 comments
[ 4.7 ms ] story [ 142 ms ] threadStill, I’d love to see more people adopt btrfs because I think diversity in filesystems is a good thing.
I like btrfs because it is just a `cinst winbtrfs` away on win32
or perhaps my impression after this recommendation is wrong and this actually isn't working well?
much confuse
I don't think there is any case where this WinBTRFS would work better than the Linux implementation, but the Linux implementation is solid enough - if BTRFS is good enough for Synology NASes (https://www.synology.com/en-global/dsm/Btrfs), it's good enough for me.
I wonder what led you to this line of thinking though. It reminds me of people being amazed at $NEWER_TECH just because it had less time to accumulate bug reports.
Yes when it became apparent that BTRFS was not ready RH did that. It was a slight surprise when it happened if I remember correctly.
I said RHEL v9 OR 10. I guess 9 is unlikely but 10 is a number of years off. If BTFS is a sucess on Fedora and stable then they will surely consider it. That is the point of Fedora...
I would agree with you. Fedora adopting stuff does not mean RHEL will include it, but if it's successful/popular on Fedora then Red Hat will surely be paying attention. RHEL tries to follow Fedora as closely as possible, I would imagine this is a shot for btrfs, but certainly no guarantee.
FWIW, SUSE is the Enterprise Linux vendor that has went "all in" on btrfs.
---
Two semi-related, personal thoughts:
1. btrfs today feels a lot like reiserfs did (going on / nearly) 20 years ago.
2. I expect Oracle to -- at some point -- integrate ZFS into Oracle (Enterprise) Linux. That seems like a great way for them to win over some "converts" from RHEL.
---
[0]: https://news.ycombinator.com/item?id=14907771
> Oracle owns ZFS. Or, rather, it bought Sun, which was the company which originally wrote ZFS. So, it doesn't really need to worry about the licensing issues.
Oracle owning ZFS doesn't magically absolve them of risk however it does reduce the risk. But with ZFS being open source, another contributor might have a claim if Oracle were to breach the CDDL license with code written by said contributor (similar to the SCO vs UNIX lawsuits of yesteryear).
To get around this Oracle would need to contact all 3rd party contributors and get the to agree to a license change. This would, in all practicality, then be reflected in a new release (like the GP suggested).
However it is now even more complicated than that because OpenZFS (which is what Linux runs) has diverged from ZFS (which Oracle maintain). So while Oracle would need to agree to any changes in the licensing of OpenZFS (as there's still Oracle code present in OpenZFS), Oracle are not the ones maintaining it and nor could they ship their own version of ZFS as Linux kernel modules to answer any concerns with either OpenZFS licensing nor compatibility with other Linuxes running OpenZFS.
There is no "just" in "just release it under [another license]". I'd written a detailed rebuttal of why it's not that simple in the GP post to yours: https://news.ycombinator.com/item?id=24331156
If Oracle wanted to ship ZFS on Linux, they would presumably port over their own version and never involve the OpenZFS team. However, Oracle created btrfs, and seem content to stick with it.
OpenZFS is a fork of ZFS rather than a reimplementation so I'd be very surprised if there wasn't any Oracle code in it (unless you're making a distinction between Sun and Oracle but legally speaking that would all still be owned by Oracle, hence why I didn't make that same distinction myself).
> If Oracle wanted to ship ZFS on Linux, they would presumably port over their own version and never involve the OpenZFS team.
Porting in this case isn't a simple task as there's a lot of "Solarisims" in ZFS that had to be worked around with the Linux port (ZoL -- ZFS on Linux -- didn't happen over night). Plus, and as I'd said earlier, ZFS and OpenZFS have diverged in terms of supported features so a ZFS volume wouldn't be compatible with an OpenZFS volume. I guess this wouldn't bother Oracle since, like most orgs of that size, they have no qualms with creating vendor lock ins. But it certainly wouldn't do much to sell Oracle Linux to the wider ZoL community.
The reason the distinction is important is that Sun released that code under the CDDL. If Oracle wanted to somehow claim it couldn't be used, it would require a massive lawsuit that would basically be against the concept of free software.
I don't understand why that would be necessary. CDDL (and equivalent) licenses don't transfer ownership of IP (intellectual property) to the public domain, they only outline usage and distribution of the code and compiled artefacts. When Oracle bought Sun, they acquired Sun's IP (amongst other things) -- hence why they could go after Google with regards to their Java IP despite Java being a Sun Microsystems creation. ZFS isn't any different, it might have been distributed under a CDDL license but since Oracle now own the copyright for ZFS code they can legally re-license that code base under another license if they wished. So Sun doesn't factor into the equation any more since what was Sun's is now owned by Oracle.
It's worth noting that you do occasionally see open source projects change their software license years after their initial release. So this isn't an untested theory.
From my understanding of open source projects released under a new license, they often can create a similar fork at the license change time where a version exists under the old license too. The exception is if they use the GPL version that allows updating the license
Nobody is suggesting they retract older version. In fact the exact opposite has been said on multiple occasions: any new license would be signified by a semver (semantic version) bump. So you're arguing against a point that was never made in the first place.
> getting rid of OpenZFS altogether
OpenZFS code would be unaffected because it's forked from a version prior to the semver re-license bump.
> From my understanding of open source projects released under a new license, they often can create a similar fork at the license change time where a version exists under the old license too.
Fork or semver bump. Which is exactly what I was talking about. Also notice that what you described there contradicts what you said would happen ("getting rid of OpenZFS") in literally the same comment.
---
If Oracle own the copyright then Oracle can re-license. They'd have to bump the version number and the previous versions with the older license would forever remain CDDL. But legally they can do it and it wouldn't affect OpenZFS licensing (aside that OpenZFS might then no longer be able to incorporate ZFS code -- assuming ZFS's new license is incompatible with CDDL. But things start to get very murky down that road.)
My argument has been that Oracle can't do this the entire time, but that's why its unfair to say there is Oracle code in OpenZFS. It makes it sound like Oracle has some power over OpenZFS, which is just not the case.
No it wasn't. You kept bringing Sun Microsystems into the discussion and they're not relevant regardless of whether we're discussing ZFS or OpenZFS because Oracle own Suns IP. Moreover, and I can't stress this enough, nobody ever suggested OpenZFS would be "got rid of" except for yourself! You created that straw man argument.
> that's why its unfair to say there is Oracle code in OpenZFS. It makes it sound like Oracle has some power over OpenZFS, which is just not the case.
It's not unfair to say that because that is the literal truth. And I was very clear about not only the distinction between ZFS and OpenZFS but also the limited scope in which Oracle could control OpenZFS (if the OpenZFS guys want to re-license they'd still need Oracle's approval for any Sun IP (which Oracle now own) that remains within OpenZFS code).
Claiming that Oracle code doesn't exist within OpenZFS or that Oracle doesn't still have a say with regards to OpenZFS's licence would be as ignorant as saying Oracle could "get rid of OpenZFS".
I suggest re-reading my initial comment that sparked this discussion. I thought it was pretty clear about the distinction between ZFS and OpenZFS and about how much/little control Oracle have over the licenses of each.
All that aside, one comment you made elsewhere did interest me: whether Oracle could sue Canonical due to copyright grounds with Oracle code in Linux. I don't know GPL well enough to know if this is possible but it's a truly terrifying thought given the amount of contributors to Linux and the prevalence of Linux in propitiatory systems like phones, routers and other places that might contain closed SoC modules.
Btrfs goes though a rapid development; so Redhat has to backport everything to their ancient 3.10 (RHEL7) kernel all the time. That's a lot of work.
Fedora, on the other hand, uses current kernels. They do not have to do this work.
Redhat also cannot choose ZFS while in the license limbo; that's why they push for Stratis.
It is stable, certainly stable enough for enterprise production use according to SUSE.
Also, do these Debian cautionary notes still apply to new code:
> There is currently (2019-07-07, linux ≤ 5.1.16) a bug that causes a two-disk raid1 profile to forever become read-only the second time it is mounted in a degraded state
* https://wiki.debian.org/Btrfs#Warnings
As for the write-only bug, 1) that only affects 2-disk RAID1 setups where people insist on cowboying around with their degraded arrays, and 2) doesn't result in data loss, merely an additional copy step to restore the array. Don't run your arrays in a degraded state, please.
As I wrote, SUSE considers Btrfs stable for production use, and they're the premier enterprise distro in Europe.
That's easy to say, but if you get a bad disk in a mirror on your boot drives, and for some reason your system restarts during this time period, you boot up into read-only mode--which kind of keeps your server down and kills service availability.
I don't run Btrfs, and so heard about this scenario from Jim Salter (the author of the linked Ars article) in his podcast:
* https://2.5admins.com/2-5-admins-03/
RAID1 is not a backup. Apparently under BTRFS, using RAID1 for HA isn’t acceptable either.
What’s the point of a RAID1 array if you can’t use it degraded? Might as well just go RAID0 too then (you have backups anyway, right?)
Like Mir, Unity, Upstart and all the other technologies Ubuntu adopted, but removed after a while again? I always have the feeling that the Canonical engineers try to advance the Linux ecosystem by introducing new technologies, but somehow always pick the wrong ones, which end up not being adopted anywhere else. Granted that's different with ZFS, as ZFS already has a large user base, but there is nothing guaranteeing that Ubuntu won't remove ZFS in a few years again.
The other projects were (for the most part) anonical originals" that they tried to create -- primarily on their own -- to replace existing products. ZFS is going on 15 years old, quite mature, highly trusted, and, of course, it already has a huge existing userbase.
It's certainly not an internal Canonical project that requires them to devote huge teams of developers to it. Unlike the others you mentioned, ZFS will continue to exist and grow regardless of Canonical's involvement.
Oof, "Canonical originals", that should have read (not sure what ate the two missing characters, HN or the iPad).
It had a long run, and it’s still more usable than gnome3 for power users. Unity wasn’t successful but wasn’t deficient.
Upstart wasn’t as good as systemd that cane after it or daemontools that came before, but it WAS an upgrade compared to the knit scripts.
Ubuntu/canonical are not afraid to try, which I think deserves more credit.
They don’t have the clout/pockets to push less popular things like systemd the way RedHat does, until all the problems are sufficiently minor.
Oh, and snap and Mir we’re both attempts at grabbing control and both deserve the scorn.
Is still used in some maintained RedHat distros, I assume this burns people like you each time is mentioned.
Probably because
>> I assume this burns people like you each time is mentioned.
is rude and borders on a personal attack.
Btrfs was originally introduced in Linux 2.6.29 in March 2009. It is still flakey in many situations.
ZFS was first release in Solaris 10 6/06 in June 2006, with it being open source almost right away. OpenZFS was forked in August 2010.
Should Btrfs at some point simply be declared a sunk cost and something new be created? Because from the outside it looks like it's hardly gaining any traction because of its reputation for eating data (maybe only with its RAID code, but still).
ZFS will never be part of the Linux kernel due to both licensing issues and it including its own crypto, cache and other subsystems.
Personally I have high hopes for bcachefs, but Btrfs is here to stay.
btrfs was removed from RHEL because RedHat themselves don't have the time or energy to support it or support systems using it. That's going to hurt adoption. Ubuntu is working actively towards ZFS as an available/default option, and once it is there's not much point in using btrfs unless you have specific use cases. Everyone else I know either uses ZFS or XFS in production. For my systems, I would definitely not trust btrfs with critical data.
Here's the thing: btrfs is 'fine', but it's not 'good'. It's the only filesystem since 2001 where I've suffered unrecoverable filesystem corruption as a result of a power outage (on a fresh 18.04 installation last November) and had to salvage data and reinstall.
The tooling, in a lot of cases, does the opposite of ZFS and touts it as a feature. For example, snapshots are not recursive and they say that this is great for if you want to snapshot / but not /home; this is true, but it also means that I cannot subdivide datasets.
For example, on ZFS I divide up /var/lib/mysql/ into /var/lib/mysql/tablespace/ and var/lib/mysql/logdb, for example, since both of those have different access patterns and block sizes (16k and 128k respectively). ZFS lets me do this to optimize reads and writes, but I can also atomically snapshot them both. btrfs doesn't let me do an atomic, recursive snapshot at all (and I'm not sure if it can handle different block sizes per subvolume either).
Basically, ZFS is a better, production-ready, enterprise-proven, and surprisingly intuitive filesystem and volume management system, and has been for 14 years. btrfs has weird tooling, incomplete features (which they don't just remove from the roadmap for some reason), data loss issues, and the only large-scale use I've heard of it Facebook, who also work on it (easier to use btrfs when you've hired all the experts).
With Ubuntu shipping ZFS enabled by default, most reasons to use btrfs go away; it's not mainlined in the kernel, but that doesn't matter if your distribution has it enabled and supported by default.
That's why btrfs RAID5/6 mode is in the sorry state it is. Nobody capable of paying the piper is interested in it. It is a domain of datahoarders, but that's not where the money is. Even Synology has put btrfs on top of mdraid for that.
Outside the parity modes, btrfs is stable and reliable. It is here to stay.
[1] https://www.zdnet.com/article/why-raid-5-stops-working-in-20...
OpenZFS is still open source and available on FreeBSD (amongst others). The licence might not be GPL compatible but the way ZFS is shipped on Linux there isn't any GPL/CDDL mixed code bases (and it's not like there isn't already a long history of GPL-incompatible software licences with Linux kernel modules anyway).
Hence, Canonical (or anyone else trying to re-release under the CDDL) cannot distribute binaries of the kernel modules.
However, you are fully allowed to compile and link the two on your own. This is why the alternative to binary distribution is compiling yourself with the help of DKMS.
As a result, it would be extraordinarily difficult for Oracle to sue since it would not be the CDDL licence terms which were infringed.
That said, boomboomsubban (https://news.ycombinator.com/item?id=24331590) suggested Oracle could sue on the GPL side of things since they have committed code to Linux. It would be interesting if such a position is possible and I suspect that could open the door to all sorts of frivolousness cases (eg closed binaries shipped with Android).
Understandably some people may be more interested in not losing their data than the licensing headaches it may come with, so ZFS it is.
Some, like yours truly, run FreeBSD on their NAS, where there are no license issues either, and are very happy it rebased on OpenZFS recently.
Btrfs has been working fine for years and is used largely at Facebook. RAID 5 and RAID 6 are still unstable (and marked as such) but the rest just works.
I get the feeling that if you are a ZFS user then RAID 5 & 6 not working is just a deal breaker.
Btrfs also has some advantages for personal use when you compare it to ZFS: it supports combining disks of different sizes and is easier to grow.
I think that's wrong. A lot of 4 drive models are in stores end users shop.
Let's not truncate this sentence to avoid altering its meaning. I certainly don't deny four drives NAS exist but I think dual bays are still a lot more common.
Anecdotally I know a lot of people with one drive NAS (some ISP provide them here), a few people with two drives NAS (including me) and no one with four drives (but I don't know anyone heavily into photography or video which seem to be the main usage).
My point was that you can still address a large segment of the home users market without RAID 5 and RAID 6.
The RAID5/6 issues are significant, but don't pretend that Btrfs would be OK if these problems were resolved. There are still many others waiting to be fixed as well.
I believe the bug which caused this is now fixed, but who really knows what other nasties linger on waiting to be triggered.
In comparison, ZFS has been a dream. I even moved terabytes of data between a Linux system and a FreeBSD server simply by swapping the discs over and running "zpool import". Superb data portability.
Has anyone had any real problems with apt install or apt remove busting their systems? Seems more like a solution in search of a problem.
You have a snapshot to go back to in that case. It saves you exactly from power-loss kind of situation.
* For expert users who have hosed a system -- particularly if it happens to be a production host -- there's an immediate sense of relief and ability to rollback safely, confidently and quickly.
* For less-experienced users who run into problems, there is a convenient and straightforward way for their technical support to explain to them how they can restore their system to a previous state.
Since hosts and their installed packages have varying hardware and configuration states and update/maintenance schedules, incompatibilities and breaking changes are likely to occur occasionally and that's where snapshots can help.
Yes, but even so it is far rarer than being frustrated waiting for f'ing grub update.
I’d think the more useful feature would be taking a snapshot at the beginning of the apt run; and then tossing it away if apt manages to complete successfully. That way, apt returning a nonzero exit status could be caught by a wrapper script, that would then transactionally revert the changes.
I believe NTFS still does this for Windows updates, even if “transactional filesystem” features are no longer “available” (i.e. exposed to userland.)
Of course, unlike NTFS’s filesystem transactions, ZFS snapshots aren’t MVCC — you can’t have multiple parallel ones going on at once that get merged on success. So that apt-wrapper-script reverting, might throw away something else you’ve done to your rootfs (and hopefully only your rootfs; such a technique would effectively require moving all user-mutable data to other mounted volumes.)
Incredibly frustrating if you don’t know about it, and incredibly helpful if you do.
> and hopefully only your rootfs; such a technique would effectively require moving all user-mutable data to other mounted volumes
I believe that zfs installation creates a separate dataset for /home, meaning that it won't be rolled back along with everything else. The same should be true for things like /var/lib/, but I haven't done such an install in a while, since the first 20.04 build with zfs enabled.
Creating ZFS snapshots is almost instantaneous due to the CoW nature of the filesystem. Is it deleting old snapshots during that process? If so, I'd suggest checking to make sure you have the async_destroy feature enabled for your pool.
* https://docs.oracle.com/cd/E86824_01/html/E54764/beadm-1m.ht...
* https://www.freebsd.org/cgi/man.cgi?beadm