Re: [Git Pull] Bcachefs
lwn.net
lwn.net
I keep an eye on Kernel developments, and have a particular interest in filesystems. Bcachefs has a lot to bring to the table and Kent is a brilliant person, but I can't recall the last time I've seen so much pushback and conflict.
Here's to hoping the adults can set aside whatever differences they have and come together in the interest of the community.
Linus looks like he's back to his old ways. I should take a closer look at illumos.
ZFS is the only other alternative to bcachefs (a rock-solid one, albeit not license-compatible), which is why it's mentioned.
Its not license incompatible, many, many, many organizations have shipped ZFS as part of the distribution and absolutely nobody ever sued or even threatened sue over the license.
Linus didn't want to merge it because of some vague fear of Oracle and how they sued over Java, but that was about API not license.
What Linus should have done is to simple upstream it. If some big company (IBM or whoever) wants to not 'risk' ZFS then they should damn well do their own work and remove it. There is no reason that the waste majority of the Linux community should be denied great features (ZFS, DTrace and friends) over some vague fear of Oracle.
Of course, all of this is highly legalistic and in spirit the CDDL and GPL are essentially identical, and from that perspective any lawsuit would be complete bollocks, but ... bollocks lawsuits do happen.
There's lots of claims about GPL and CDDL compatibility floating around and much of it sounds at least plausible and it's all a bit controversial. Clearing up this sort of confusion is exactly the sort of scenario where courts come in to play. So it seems to me that fears of a lawsuit are not entirely unreasonable.
Do you want to put all your money and the future development of Linux at risk? The nature of lawsuits in the US means that as soon as the lawsuit is filed you've lost already, and the ruling just decides if you've lost even harder.
Not denying Linux can have its share of NIH, but I see this mostly as a matter of risk management. e.g. Canonical has decided to take that risk, which is fair and reasonable, but Linus decided to not take that risk, which is also fair and reasonable.
Of course the entire situation is ridiculous; btrfs is partly sponsored by Oracle, and Oracle is also sitting on a perfectly functional filesystem they can just relicense like they did with dtrace. I don't know what's preventing Oracle from doing that.
If you really believe there is a license issue go ahead and start suing people and see how far you get with that.
> So it seems to me that fears of a lawsuit are not entirely unreasonable.
And yet lots cooperation shipped code and products with ZFS and Linux with no issue what so ever for many, many years now.
> Do you want to put all your money and the future development of Linux at risk?
Its not a risk for Linux at all. Its a risk for a company that distributes Linux with ZFS in it. If a company for some reason believes that there might be an issue and they don't want it, then they can feel free to remove it.
My guess is that 99.9% of companies will simply use Linux with ZFS in it.
> Linus decided to not take that risk, which is also fair and reasonable
He could just say he would merge it, and unless half the large cooperations in the world jump on him to stop him there is no reason to not merge it. But he didn't do it, he just reject it out of hand based on some vague 'maybe oracle' something. Did he consult a lawyers?
That distros haven't been sued yet seems meaningless. Granted, Oracle has been a bit better in recent years, but people haven't forgotten Oracle v. Google, SCO v. {everyone}, USL v. BSDi, etc. One of the lessons is that you can never know who will own some piece of copyright or IP in the future and what they will do with it. Oracle could off-load all of the Solaris stuff to some copyright troll tomorrow.
But it doesn't really matter who is right or wrong here or if it is or isn't compatible: there's enough of a dispute for lawsuits, and they're going to be costly and a headache anyway.
I don't think if meaningless. And its not just distros, there are whole companies whos buissness model depends on linux with zfs. And its also all the companies who use the distros.
Literally 100s and 100s of company are running Ubuntu. All of those companies have decided that ZFS isn't a problem of them. All of them could have ask to exclude ZFS but non have to my knowlage.
Its also not really about Oracle. Sun did the legwork when they open-sourced their stuff. Those licenses in itself are not in question. And those licenses certainty don't care about being linked with GPL. The only question is if GPL is incomparable with the CDDL.
So the fear of Oracle in this case that Oracle would put itself forward as defender of the GPL? That makes no sense. But anybody could sue anybody about that at any time.
If Linux had included ZFS the ZFS code would already exists on most of the worlds computers by now. And the waste, waste majority of companies would not remove ZFS over some open source inside baseball.
I don't think fear of Oracle is the issue, more likely just an irrational rejection of everything Sun and Solaris. After all btrfs also originated in Oracle (what's worse, despicable Oracle itself, not via the Sun acquisition).
Perhaps Oracle's unwillingness to relicense is simply that Oracle knows how inferior btrfs and thus doesn't mind giving it away by licensing it GPLv2, but ZFS is much more valuable and they want to keep the rights to it as potential competitive advantage. If Sun hadn't licensed ZFS CDDL before the acquisition, I'm pretty sure Oracle would be happy to keep it closed-source.
I hope bcachefs makes it into the kernel quickly, that distros drop btrfs and that its infiltrators are turfed out of kernel-land, but that's probably too much to hope for. In the meantime, I am happy to keep running ZFS for all my critical data on Illumos, Alpine and Ubuntu.
> I don't think fear of Oracle is the issue
Why then did Linus say exactly that?
> After all btrfs also originated in Oracle (what's worse, despicable Oracle itself, not via the Sun acquisition).
Wrong. It was simply a guy that worked for Oracle, it wasn't an Oracle project.
> Perhaps Oracle's unwillingness to relicense is simply that
It doesn't matter what Oracle once, of course they don't want anything to do with ti. The community has forked ZFS long ago and Oracle has no power what so ever to reliance most of that code.
Literally nobody wants the Oracle proprietary ZFS anyway.
This licensing issue is the reason bcachefs exists.
Here's this big project that Kent's been wanting to merge for ages and very basic steps that any Kernel developer would be aware of (like sending it to linux-next first) have not been done.
Yes Kent isn't following the right process but he made a more fundamental mistake: getting involved with Linux development at all.
I hate building external modules, ZFS has never seemed worth the trouble to me. Why do you care so much?
https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
I have had Btrfs collapse and corrupt itself more in the last half a decade than all other Linux filesystems put together this century.
If you fill the volume, it will fail, and its own repair tools do not work and will damage it further. I would not and do not trust it.
Your anecdotal evidence about data loss is meaningless. I can counter with my own anecdote: I've had zero data loss with btrfs running pre-release RC kernels on my laptops for over a decade. I fill up disks a lot.
One failure report is worth 1,000 success reports. Add as many orders of magnitude as you wish, and the statement remains true. This is not merely an axiom of reviewing and assessment, it's a joke:
I've been reviewing tech for a living for nearly 30 years now, and evaluating tech for a living -- as well as using it and fixing it and deploying it -- since the decade before that.
The point of tech assessment and tech reviewing is to balance the good features against the bad features. Too many people get dazzled by the good stuff so that they don't notice the bad stuff.
As the late great Douglas Adams put it:
« In other words - and this is the rock-solid principle on which the whole of the Corporation's Galaxywide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws.” »
I don't care how good the features of a filesystem are if I can't trust it. Either it needs to be very solid, and have good documented battle-tested tools for fixing it and repairing it, such as XFS or JFS... which probably means it is also conservative on the features.
Or, alternatively, absolutely blasted bulletproof, to the extend that a multi-billion-dollar corporation sees fit to launch it without a repair tool because it doesn't need one.
There is one such system, and it is ZFS.
Btrfs is neither. It is loaded with features, some half implemented if that, it is fragile, and it does not have good repair features.
If I had seen it fail once, I would be dubious and sceptical.
If I had seen it fail twice, I would no longer trust it.
But I have not. I have seen it fail half a dozen times in 4 years.
And it is not just me.
Here is the documentation on the repair tool:
« Warning
Do not use `--repair` unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume. »
Source: https://btrfs.readthedocs.io/en/latest/btrfs-check.html
Here is #1 corporate user SUSE's:
« WARNING: Using '--repair' can further damage a filesystem instead of helping if it can't fix your particular issue. »
Source: https://www.suse.com/support/kb/doc/?id=000018769
In corporate terms, this is an admission.
This tool cannot be trusted and that it is present means that the FS cannot be relied upon.
This is a giant red flashing light and eardrum-bashing warning siren.
It doesn't matter how many people like it and have had no problems. THERE ARE PROBLEMS. It doesn't matter how many corporates use it. A broken tool may still be usable.
Meta may deploy Btrfs across racks of kit but they don't care about the data on those racks and it can be replaced.
Fedora doesn't use snapshot support because it's bodged that functionality into OStree so it doesn't care if it's dangerous. It just wants to describe how horrendously inefficient Flatpak is.
1. If you are writing with the `single` profile. It always writes to the one with the most space. This means that adding a new disk to a system will hotspot writes to that disk. Alternatively you can rebalance and it will make it so that all disks have the same space available which will basically hotspot reads. Most sane filesystems will do some sort of balancing.
2. If you are writing to the `RAID0` (striping with no redundancy) it will write across all disks and fill them up equally. When one disk fills it will be dropped out and the other disks will be hotspotted.
3. If you read from a replicated profile it picks the disk based on your process ID rather than any sort of intelligent metric like queue length or typical latency.
4. Replication profile can only be set on the filesystem level. bcachefs can set replication profile on the per-file or recursively at the directory level.
I mean nothing is absolutely terrible. But it is just shockingly basic for many things.
Realistically, that's a basic requirement for any filesystem. I've not had a filesystem do that in my two plus decades of linux usage. That means I'm just not using it. Restored to ZFS from backup and couldn't be happier. ZFS works; is extraordinarily stable; and hasn't lost data for me yet.