Bcachefs Looks Like It Won't Make It For Linux 6.6

[mdedetrich]

In reality if Linux didn't have a CoW filesystem it would be a loss for users but otherwise virtually nothing would change. The only other OS that's actually relevant in the real world is Windows, and it doesn't have a CoW filesystem either (ReFS has been around for more than a decade and still us not really usable. Freebsd fanboys will always hate Linux because reasons no matter what so that's neither here nor there.

CoW filesystems don't give that much benefit for typical desktop users so no idea why you are bringing up Windows. Their biggest benefit is actually NAS/enterprise storage (Facebook/Oracle are after all one of the heaviest users of BTRFS).

And the ironic thing here, one of the biggest competitors in this regard is FreeBSD/TrueNAS with ZFS. TrueNAS has already released a version of their OS built on Linux (called TrueNAS Scale) but it uses ZFSOnLinux.

[oiaohm]

Again if other maintainers are having issues deciding whether or not it should go into next, I don't think it's far-fetched to get input from linus. When it came to iomap, he explicitly listed the issues he had with it, and said until they get fixed, it's not an option that's on the table. and He didn't accuse everyone of that, he accused a couple of people of things they were doing. When someone gives a "No." and you ask "Why" when you get ghosted, that is understandably very aggravating.

Yes, he did bypass the correct channels, Now with linux-next, I have seen multiple kernel developers now on various channels criticizing the inclusion processes. This is not just a "Kent did bad" situation evidently.

as for the VFS stuff, I'm not entirely sure whats going on with this, the VFS patch that bcache posted did get ack. Kent has been non stop asking for more information and correspondance and then one getting ghosted, yes, he certainly was out of line at times, but pretending that no one else was is just a blantant and shitty attack against kent

One of the heads of VFS had told him back june/july to put bcachefs in linux-next. Being ghosted when you are not following instructions by head maintainers does happen.

Yes Kent also said he would take it up with Linus so he did not have to listen to the VFS maintainer.

Yes Kent decided to go over the VFS maintainer to basically his supervisor then he is surprised that all the support staff of the VFS maintainer stops reviewing his code.

Yes going to Linus Torvard directly has a problem he normally does not process new code entering the kernel. Other maintainers have checked basically things normally before Linus sees it. Yes code in next and patch checklist followed are things Linus normally don't have to check. Again stuff Kent had already been told todo before the VFS maintainer and support staff dropped bcachefs. Yes the only dropped when Kent said he was going over their authority.

Actions have consequences. Also just because you get away with doing something wrong in the short term does not mean it a successful move long term.

Please note there is a difference between being a just Linux kernel developer and being a Linux kernel maintainer. Yes a lot of just Linux kernel developers really hate that they need to get maintainer sign before they can push anything to Linux-next.

[mlau]

LKML is getting extremely toxic!

Can you point to a concrete example of this toxicity?
Because in my pov, this argument is always brought up whenever someones work is rejected/critizied for whatever reason (or someone interprets criticism of his/her work as a personal attack).

[reba]

Well, there have been some slips in the recent times, that's true.

The PGP thing should not have even happened. If I understood correctly, commits have to have a paper trail on them and need to be PGP signed. If this is mandatory, how could commits have happened inthe first place? If it is necessary, enforce it. That way, that issue would have been found much earlier. But there is probably a reason I don't see from the outside.

Then the thing not first having gone though next. I think all sides are to blame here, Kent because he could have known this, Linus because he just assumes (then again, he probably has other stuff on the table) and all the other maintainers who probably all could have seen at some time and noticed the "next" stage has been omitted. I don't think this happened in bad faith from any of them but for me this indicates a missing automatism (just like above) that could have helped by enforcing here.

But then all the commits now first have to go to next, and I understood there are some bot-gates to cross here, then I think we won't see bcachefs before the end of this year, because those bots seem to be the only thing working correctly in all this mess: automatic enforcing. And this is a hurdle all of Kents code first has to go through. Will it pass in the first run? the first ten? who knows? AMD made their experiences with it so I just hope, Kent, as a kernel developer, has had enough muscle memory (see above *sigh*) to write the code right from the beginning to pass most of the bots unnoticed.

I really would like to see bcachefs upstreamed but I think there are processes to inspect. If this happens, at least something very good came out of this mess.

I can't recommend anything because I am just too far away from it, but someone mentioned systemd on a git hosting platform and their issues. Yes, they currently have 10536 issues of which are 1901 open, but honestly, I feared much worse and it shows they managed to close a whopping 8635 issues, so there is progress. And the transparency and traceability of it all is something I really appreciate.

Does anybody know how the systemd guys organize their workflow? Kanban? Anything?

[partcyborg]

Using a mailing list to handle patches for something as large as a kernel is seriously assbackwards.

The linux kernel hasn't been developed with "patches on a mailing list" since sometime around 2005 when it moved to git. The emails are only "pull requests", the code is all managed by git. Linus literally developed git to manage the linux kernel so emailing patches around wouldn't be necessary anymore

Linux process could be better indeed. I landed a single line change a while ago, it required a lot of setup, tweaking Thunderbird (and failing to format message properly anyway because of long-standing Thuderbird issues) and in the end it was a very frustrating and long process with a lot of correspondence back and forth.

Compare that to a simple pull request process through platforms like GitHub, GitLab and similar.

Linus has explicitly stated in the past that the github/gitlab models are insufficient for the linux kernel because they rewrite commits in such a way that you lose the true commit history.

I 100% agree that they need a better review UI than email but github/gitlab has its own issues

[Quackdoc]

One of the heads of VFS had told him back june/july to put bcachefs in linux-next. Being ghosted when you are not following instructions by head maintainers does happen.

You mean the VFS maintainer that had an issue with something, so kent asked about it and got ghosted? yeah I would try and ignore him too then.

Yes Kent also said he would take it up with Linus so he did not have to listen to the VFS maintainer.

Yes Kent decided to go over the VFS maintainer to basically his supervisor then he is surprised that all the support staff of the VFS maintainer stops reviewing his code.

they didn't, he did actually get reviews from some people, just not the people in question

Yes going to Linus Torvard directly has a problem he normally does not process new code entering the kernel. Other maintainers have checked basically things normally before Linus sees it. Yes code in next and patch checklist followed are things Linus normally don't have to check. Again stuff Kent had already been told todo before the VFS maintainer and support staff dropped bcachefs. Yes the only dropped when Kent said he was going over their authority.

yeah well when you get ignored by the VFS maintainer you need an ack from, you lack other options,

Actions have consequences. Also just because you get away with doing something wrong in the short term does not mean it a successful move long term.

Please note there is a difference between being a just Linux kernel developer and being a Linux kernel maintainer. Yes a lot of just Linux kernel developers really hate that they need to get maintainer sign before they can push anything to Linux-next.

I know the difference between a maintainer and a developer, maintainers have that nice M: beside their name in the MAINTAINERS file. Kent is a maintainer of bcache, he is not wholly unfamilar with the process, I also mentioned another maintainer too who has expressed that the system is more confusing in the bcache IRC channel.

[mlau]

The issue though is that I need to configure a very specific workflow that is unique and uses very specific tools in a very specific way just to contribute a single line change to the kernel. For example I need to use email to send code, I need to send it in plain text, if the email client I use literally for everything else I need to set up sending patches via CLI somehow, figure out how to store credentials for it such that I neither need to enter them every time nor store in files in plain text. That is a HUGE barrier for anyone considering to contribute even remotely. Heck, I suffered with commit messages, I was trying to figure out how do I format the message to not exceed imposed length limit because apparently someone uses 30 years old monitor without horizontal scrolling capability or text wrapping and will be unable to read it otherwise.
.

These "hurdles" can be overcome in 10 minutes and need to be done once. I remember long ago someone on the mailing list remarked that these hurdles also act as a filter: if you cannot even be bothered to invest a bit of time to learn the customs of a project, maybe we don't want to have to deal with you.

[jacob]

CoW filesystems don't give that much benefit for typical desktop users so no idea why you are bringing up Windows. Their biggest benefit is actually NAS/enterprise storage (Facebook/Oracle are after all one of the heaviest users of BTRFS).

And the ironic thing here, one of the biggest competitors in this regard is FreeBSD/TrueNAS with ZFS. TrueNAS has already released a version of their OS built on Linux (called TrueNAS Scale) but it uses ZFSOnLinux.

CoW brings the same benefits for desktops as for servers or enterprise systems. In fact the only two workloads that are notoriously CoW-averse are databases and virtualisation, those are not typical desktop uses Anyhow, the majority of the world's enterprise systems run Windows.

[Old Grouch]

In reality if Linux didn't have a CoW filesystem it would be a loss for users but otherwise virtually nothing would change. The only other OS that's actually relevant in the real world is Windows, and it doesn't have a CoW filesystem either (ReFS has been around for more than a decade and still us not really usable. Freebsd fanboys will always hate Linux because reasons no matter what so that's neither here nor there.

Linux does have at least one Copy-onWrite (COW) filesystem: NILFS2

NILFS2 is a log-structured file system (LFS) supporting continuous snapshotting. In addition to versioning capability of the entire file system, users can even restore files mistakenly overwritten or destroyed just a few seconds ago. Since NILFS2 can keep consistency like conventional LFS, it achieves quick recovery after system crashes.

NILFS2 creates a number of checkpoints every few seconds or per synchronous write basis (unless there is no change). Users can select significant versions among continuously created checkpoints, and can change them into snapshots which will be preserved until they are changed back to checkpoints.

There is no limit on the number of snapshots until the volume gets full. Each snapshot is mountable as a read-only file system concurrently with its writable mount, and this feature is convenient for online backup.

[timofonic]

Linux does have at least one Copy-onWrite (COW) filesystem: NILFS2

But who uses NILFS2?