Linus Torvalds Reviews The Bcachefs File-System Code

malaizhichun

malaizhichun

The long-in-development Bcachefs file-system driver was submitted for Linux 6.5 but never merged this cycle due to various technical issues and developer in-fighting. Linus Torvalds himself has now gotten around to reviewing the proposed code and chiming in on the situation.

Linus Torvalds yesterday finally was able to wrap up his review of the Bcachefs code. He's voiced his concerns around some of the locking code and that some of the Bcachefs prerequisite code should go in via the respective subsystem/maintainer branches rather than one big monolithic pull.

Torvalds' current position on the Bcachefs state for merging basically comes down to:
"So as things stand now, the stuff outside bcachefs itself I don't find objectionable.

The stuff _inside_ bcachefs I care about only in the sense that I really *really* would like a locking person to look at the six locks, but at the same time as long as it's purely internal to bcachefs and doesn't possibly affect anything else, I'm not *too* worried about what I see.

The thing that actually bothers me most about this all is the personal arguments I saw. That I don't know what to do about. I don't actually want to merge this over the objections of Christian, now that we have a responsible vfs maintainer.

So those kinds of arguments do kind of have to be resolved, even aside from the "I think the prerequisites should go in separately or at least be clearly acked" issues."
Click to expand...

All of Torvalds' review comments can be read in this mailing list thread.
Bcachefs command


Lead Bcachefs developer Kent Overstreet has expressed interest in re-submitting for Linux 6.6, so we'll see if the Bcachefs issues and developer arguments are able to cool down within the next few weeks.
 
So, another square wheel invented there? Or is it something serious this time?
 
So the "not invented here syndrome" spawned yet another attempt of a file system, that will never be production-ready and forgotten in a few years?
 
If you ask me, I can think of one or two other pieces of Linux shioftware that could benefit from a Linus' code review. Provided with arguments too. :p ;)
 
sko said:
So the "not invented here syndrome" spawned yet another attempt of a file system, that will never be production-ready and forgotten in a few years?
Click to expand...
Some of the links over on phoronix go back to 2018. I'm not bothered anymore by the "not invented here" aspect in software anymore as long as the reinventors actually learn from the other which they often don't.

Adoption of a new filesystem is always tricky/interesting. Initially it needs to get enough done and stable for people to try it out, comparisons against existing FS will be done, then you can get into "well it's not finished yet so don't rely on it for real data" and nowadays we wind up with the "can it be used on another OS, even in a read only mode" is pretty important.

The fact that the feature set sounds a like ZFS implies a good comparison can be made at some point in time.
 
From bcachefs:
"The COW filesystem for Linux that won't eat your data".
Click to expand...
Stating that as the title heading at the home page of your website tells me that this (apparently) must be emphasized for bcachefs. It implicitly implies that there are other filesystems for Linux that do eat your data. Immediately after the first sentence when reading the first bullet point zfs and btrfs are mentioned as other COW filesystems; a link from the title to those two filesystems is easily made—being intentionally written that way or not.

I don't find the "catchy" title particularly appealing or strong when referring to a fundamental property of a filesystem:
a filesystem does not eat its [user] data.
 
Erichans said:
It implicitly implies that there are other filesystems for Linux that do eat your data.
Click to expand...
BtrFS has a reputation for being so buggy that it causes data loss. Which makes me sad, because it is based on good ideas. BcacheFS also has some very interesting ideas (the hybrid between tree structure and logs, with the log inside tree nodes), and I would like to see how those fare in the real world. The underlying problem is: To have a file system evaluated on a large set of workloads, in normal (unmanaged non-specialist) operating conditions, it first needs to be widely distributed, and it needs to be bug-free enough to be reliable.
 
  • Like
Reactions: mer
I don't understand, why don't they import Hammer from DragonFlyBSD. ZFS has a licensing conflict with GPL, but they keep insisting on using it, leaving everyone to question whether they're allowed to use it alongside an incompatible license.
 
Maybe they should go the whole hog and run their git repos on their file systems also. Like, btrfs or now bcachefs. That will increase their understanding for the need of stability and correctness.
 
Crivens said:
Maybe they should go the whole hog and run their git repos on their file systems also. Like, btrfs or now bcachefs. That will increase their understanding for the need of stability and correctness.
Click to expand...
Many years ago, I started work in a new job, which was a file system. The first thing I did was to set up a computer, install the prototype filesystem. Then I downloaded the source code for the file system (which came in a tar ball), and untarred it onto itself. That actually worked, which amazed my colleagues. The I cd'ed into it, and said "make". I think it was less than a second before everything blew sky high. Then I spent a year or two documenting and debugging the internal RPCs, and writing synthetic benchmark tests, before we were able to self-host on our new file system.

While it might sound nice to say "eat your own dogfood" and "the best way to debug something is to use it for your own needs", in reality that is foolish. In the real world, 99.9% or more of all file system workloads (or in general storage workloads) are NOT like a small software development server/workstation, or running git and make. If you force file system developers to develop and test on their own system, you might bias to also optimize for that unusual workload, and test only on it, which would leave the file system unprepared for the real world.
 
The amount of testing, and test planning, that went into ZFS is enormous. To reach that level of stability you would need to play catch-up for many many man-years. And then you'd have something that is only better by the width of a hair (maybe). I wish them good luck with bcachefs, may it turn out better that btrfs. And it may keep people busy which would otherwise try to add nice features (tm) into OpenZFS...
 
sidetone said:
There's speculation that Sun wanted to make an incompatible license to the GPL, before making that. There's arguments that claim, Canonical can use them together, maybe through a patch, module layer or through an API, but it's unclear.
Click to expand...
So, the legalese of the license (CDDL) is nullified by adding a layer of programmatic complexity. I would assume the stipulation was originally meant to solve future problems now. Now that same technique is used to provide the opposite effect? Is this irony? ?
 
Erichans said:
It implicitly implies that there are other filesystems for Linux that do eat your data. Immediately after the first sentence when reading the first bullet point zfs and btrfs are mentioned as other COW filesystems; a link from the title to those two filesystems is easily made—being intentionally written that way or not.
Click to expand...
It is a somewhat unfair dig at btrfs - I am pretty sure btrfs is reliable apart from in certain RAID configurations that the documentation tells you not to use.It is the default file system for Suse and their paying customers would not be amused by data loss.

The big advantage of bcachefs from a Linux point of view is that the code can be included in the kernel.
In the meantime ZFS is a reason to use FreeBSD rather than Linux.

sidetone said:
I don't understand, why don't they import Hammer from DragonFlyBSD.
Click to expand...
Hammer is only an year older than btrfs, and Hammer2 is actually younger. bcachefs is a newer, but based on bcache which has been around for a while.
 
The camps disagree with each others licensing terms. They wanted their ecosystems separate, or to not have so much influence. It was which license camp would win over.

The GPL camp said how the CDDL was horrible and infringed on freedoms, when that wasn't the case. It conflicted with their idea of open source. When I looked at it, CDDL doesn't infringe, and it's freer than GPL. That incompatibility allows CDDL to keep more permissive terms. People fear that GPL will make claim on their own proprietary code for using it. The CDDL was meant to provide an alternative ecosystem than the GPL.

The GPL camp also said how BSD licenses are ok, but they don't recommend them, because the BSD disclaimer has to be kept in, and they don't want to bother with that. They discourage licenses which are compatible, because they want to absorb without having to keep a BSD license disclaimer in. Then, others say how BSD and MIT licenses are good for libraries that GPL uses.

There's a place for both types of licenses, provided that compatibility layers are used. If licenses proliferate, CDDL and similar types will be more compatible for use with more types of licenses.

The problem Sun was trying to solve (by use of the CDDL) wasn't a technical one, as much as an ideological one.
 
sidetone said:
The problem Sun was trying to solve wasn't a technical one, as much as an ideological one.
Click to expand...
I disagree.
ZFS is solving a problem, a technical one. 64 bit native FS, supporting storage a heck of a lot larger than UFS/EXT2-3-4/whatever else is the root of what ZFS was doing.
 
That was in reference to creation of the CDDL by Sun.

by use of the license on its products including ZFS. ZFS is obviously solving a technical problem.
 
  • Like
Reactions: mer
Erichans said:
It implicitly implies that there are other filesystems for Linux that do eat your data.
Click to expand...
Shouldn't this be a Hippocratic Oath for filesystems? "First, eat no data."

I'm with ralphbsz that the only way to get close to that before release is extensive testing. Unfortunately that's something the open source model does not do well. The MO is to unleash partly-finished code on the masses and let them test it for you. That has some significant downsides when it comes to file systems.
 
Last edited:
Erichans said:
From bcachefs:

Stating that as the title heading at the home page of your website tells me that this (apparently) must be emphasized for bcachefs. It implicitly implies that there are other filesystems for Linux that do eat your data. Immediately after the first sentence when reading the first bullet point zfs and btrfs are mentioned as other COW filesystems; a link from the title to those two filesystems is easily made—being intentionally written that way or not.
Click to expand...
Well, Btrfs unfortunately does eat your data. I mean, Btrfs is nothing but a bad ZFS copy cat/rip off, development started in 2007, integration into the kernel was in 2009! This whole ugly beast is now over 16 years old, and still comes with its own official list of stuff it can do on paper but you should not do in real life if you do value your data safety, like RAID5/6. Have a look here: https://btrfs.readthedocs.io/en/latest/Status.html

Just this little piece already does not instill much trust into the whole shebang:

1693331532743.png


Btrfs is also just slow as molasses, and not ready for anything aside RAID0/1.

There've been also several Linux distributions who tried to use it as default file system in the past, some even did - and got burned, like CoreOS. In CoreOS Btrfs was about one year the default file system since 2014, or something. The result of this was an own wiki page containing best practices on how to deal with all the potential errors by Btrfs, and after a year a petition to move back to ext4, which was successful.

More coverage in the LWN: https://lwn.net/Articles/627232/

Highlights: "CoreOS users have regularly reported bugs against btrfs including: out of disk space errors, metadata rebalancing problems requiring manual intervention and generally slow performance when compared to other filesystems."

"The out-of-space / metadata balancing problem has bitten me more times than I care to count. It's essentially a fact of life that I have to blow away /var/lib/docker and all its subvolumes every few weeks on any given machine, to clear an out-of-space problem (though `df` shows a usage of, say, 30%)."

Since including ZFS directly into the Linux kernel would violate the CDDL license, which is the main point of that license, this means that Linux has no production ready COW file system in the mainline kernel. Of course people can just compile ZFS on Linux, and be happy with that.

The developer of Bcachfs, Kent Overstreet, started his little pet project Bcachefs after he came to the realisation that Bcache already contained much stuff a new COW file system in the kernel needs. And also because he felt the need for a GPL covered COW file system in the Linux kernel, which is able to replace Btrfs.

The XFS maintainer in the Linux Kernel, Dave Chinner, so far seems quite impressed with that effort, and supported it in the past.

So since all sane people do agree about that Brtfs will never be useful aside for pet systems, because it just sucks and its development as well, another stable COW file system in the Linux mainline kernel is a thing many people want to have.

For reference: it took Sun only 4 years to develop ZFS, development started in 2001, and it became part of Solaris in 2005.
 
hardworkingnewbie said:
Well, Btrfs unfortunately does eat your data. ...
There've been also several Linux distributions who tried to use it as default file system in the past, some even did -
Click to expand...
As far as I know, BtrFS remains the default file system on SUSE's enterprise edition. Honestly, I don't understand that. On one hand, I have heard from many people that BtrFS has lots of bugs, many of which cause data loss. On the other hand, I assume the good people at SUSE are not fools, and would not ship a system that eats data to their paying customers. I don't know how to resolve that contradiction.

For reference: it took Sun only 4 years to develop ZFS, development started in 2001, and it became part of Solaris in 2005.
Click to expand...
Two comments here. First, Sun did't start from scratch: It had QFS (acquired from a smaller company), which gave it an excellent technology base by including volume management and archival storage. It had access to the traditional Unix file system source code. It had a lot of people in its storage group, and quite a few of them I know and respect highly. It also had enough money to hire a large pool of engineers and testers for ZFS.

Developing a new single-node file system in 4 years with a large team (hundreds) is perfectly doable.
 
You must log in or register to reply here.
Back
Top