OpenSUSE disables bcachefs [LWN.net]

The openSUSE project has announced that the bcachefs filesystem will be disabled in its kernel builds starting with 6.17; bcachefs users will have to make other arrangements. "The current 6.16.* is NOT affected. Neither is Slowroll (for now)."

to post comments

Dog piling

Posted Sep 10, 2025 14:58 UTC (Wed) by mh3f (subscriber, #103724) [Link] (8 responses)

> Once the BCacheFS maintainer behaves...

Geez, I feel like every one is dog piling on Kent at this point. I've been following the issue off and on, and I find these types of comments unproductive and patronizing.

Dog piling

Posted Sep 10, 2025 15:58 UTC (Wed) by proski (guest, #104) [Link]

Agreed. Not funny and not helpful at all.

Dog piling

Posted Sep 10, 2025 19:55 UTC (Wed) by warrax (subscriber, #103205) [Link] (4 responses)

Yeah, that's not constructive.

I definitely agree with them disabling a filesystem they don't have a viable support channel for, but that's just... too much.

Dog piling

Posted Sep 10, 2025 20:31 UTC (Wed) by rustylife (subscriber, #102864) [Link]

i would like Jiri Slaby to behave

Dog piling

Posted Sep 10, 2025 23:26 UTC (Wed) by khajdamowicz (guest, #179281) [Link] (2 responses)

Honestly? I guess nobody looked for support at distro maintainers and hit Kent directly.

As fs/bcachefs is now "Externally Maintained" I think that kernel maintainers should pull content of that directory straight from repo of external maintainer, Kent Overstreet, from branches like bcachefs-for-6.xy.
There's no word of declaration that bcachefs is removed now, it's just not updated in Linus Repo and it's already pointed that support is external to this repo.

Externally Maintained

Posted Sep 11, 2025 9:22 UTC (Thu) by gherkin (guest, #177675) [Link] (1 responses)

Also, bcachefs is the *only* item listed as "Externally Maintained" - and I've yet to see any clarification of what that actually means in terms of processes.

Surely it is either supported by the maintainer, or it isn't? Is the maintainer able to submit patches for the sections they maintain or not? How is maintenance meant to be possible if patch submission is not possible? Is "Externally Maintained" just a euphemism for "Code frozen and deprecated, and will be removed from this repository"?

If so, it would be helpful if that was actually stated, rather than relying on hearsay, rumour and guesswork.

The lack of clarity is quite concerning, from a user-centric point of view, as clearly private/internal discussions have taken place, but no-one seems to think it's worth informing the users what is going on?

And I do find quite disappointing the quantity of comments similar to the 'maintainer behaves' line, for example the various 'needs help/therapy' comments in lkml, which are unconstructive at best.

Externally Maintained

Posted Sep 11, 2025 10:25 UTC (Thu) by tux3 (subscriber, #101245) [Link]

>The lack of clarity is quite concerning, from a user-centric point of view, as clearly private/internal discussions have taken place, but no-one seems to think it's worth informing the users what is going on?

I don't think that's the best way to paint the situation. What was extensively discussed is that Linus Torvalds was not going to be pulling from Kent Overstreet's branch. fs/bachefs being ripped out right in the middle of the 6.17 cycle, instead we got a somewhat more restrained response.
Externally Maintained is some polite wording for a complicated human situation, that's all you should read into it. As far as I know Kent found out about that commit at the same time as the rest of us.

It's been a couple weeks and the situation seems to have settled now, so I would be very surprised if /fs/bachefs is not removed by the time 6.18 releases. It's not like there was more than a 5% chance of things turning around after "Externally Maintained", but I would have been happy to be surprised, and for a fleeting moment, the door had not fully shut.

Fwd: Re: Dog piling

Posted Sep 11, 2025 10:41 UTC (Thu) by tux3 (subscriber, #101245) [Link]

Since the conversation is split, it is easy to only see the comments and miss the reply: https://lwn.net/ml/all/bece61a0-b818-4d59-b340-860e94080f...

>>On 10. 09. 25, 9:16, Jiri Slaby wrote:
>> Once the BCacheFS maintainer behaves and the code is maintained upstream
>> again, we will re-enable... (As IMO, it is a useful feature.)

>OK, I taught myself (by reading the LWN thread), this sounds too harsh
>in English. It was not intended as such. Neither as a kick. Translate
>the above rather as: "Once the bcachefs maintainer conforms to the
>agreed process and the code is maintained upstream again, we will
>re-enable...".
>
>If the above offended anyone, I sincerely apology them.
>
>thanks,
>--
>js
>suse labs

Dog piling

Posted Sep 11, 2025 21:59 UTC (Thu) by jmalcolm (subscriber, #8876) [Link]

> I feel like every one is dog piling on Kent at this point

As somebody that has been critical of Kent's behaviour, I would like to say how mature I found his response to Jiri to be. I think the decision by OpenSUSE is less fair than anything Linus did and Kent yet responded quite reasonably. He asked (yes asked) if the action could be deferred, he provide reasonable arguments, he did not trash any other project or process, and he actually advocated for his users. Amazing!

As I am not using OpenSUSE, it does not help me at all but I would nevertheless like to publicly applaud Kent and thank him for his communications and approach here. If we would have had more of this on the LKML, we would not be where we are.

Great job Kent. More of this please.

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 15:33 UTC (Wed) by pschneider1968 (guest, #178654) [Link] (20 responses)

The last statement in the openSuSE announcement is just plain ridiculous and absolutely brazen IMHO.

To me, as an outside observer, this seems to be kind of a distributed bullying attack, or should I say: Distruted Denial of Decency (DDD) attack on Kent Overstreet. When there are technical or process disagreements, they need to be discussed and sorted out in a civilized manner. But these kinds of ad hominem attacks need to stop, because they are intolerable!

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 16:27 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

> The last statement in the openSuSE announcement is just plain ridiculous and absolutely brazen IMHO.

WTF is even the point of saying something like that? Or, for that matter, any of this OBVIOUSLY-true-because-everyone-says-so dogpiling?

That statement is a textbook example of abusive "why do you keep making me beat you?" behavior, and I'm disappointed (but not surprised) to see this whole situation careening into legal-consequences territory.

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 17:49 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (2 responses)

> WTF is even the point of saying something like that?

Much of today's FOSS community spends free time on social media networks full of sanctimonious distributed bullying and attempts to cancel people for violations of what they perceive as social norms. Is it any wonder that this culture has leaked into official announcements?

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 18:19 UTC (Wed) by npws (subscriber, #168248) [Link]

> Much of today's FOSS community spends free time on social media networks full of sanctimonious distributed bullying and attempts to cancel people for violations of what they perceive as social norms.

You really think so? I wouldn't expect people that actually have something useful to waste their time on this garbage.

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 11:54 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

I think it is a very vocal minority and most people do not even read the drama and are only vaguely aware of it. And if they are aware they stay silent to not be involved.

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 18:03 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> That statement is a textbook example of abusive "why do you keep making me beat you?" behavior, and I'm disappointed (but not surprised) to see this whole situation careening into legal-consequences territory.

I agree that we shouldn't be dog-piling but I expect zero legal consequences for saying anything that the announcement is saying. The only practical consequence is less distribution support. That became clear as soon as Linus made his announcement.

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 18:27 UTC (Wed) by vbabka (subscriber, #91706) [Link] (14 responses)

While the statement isn't written in a particularly diplomatic and polite way, I don't think it was meant in the bad way that it looks to some commenters (note also the "IMO, it is a useful feature" part). Seems to me just more thought was needed as to how the statement might sound.

But at the core it's stating the fact that bcachefs is now externally maintained because Linus (and apparently also other maintainers) were unhappy with Kent's behavior, and not e.g. due to submitting broken code. So to become maintained, that behavior would have to change. Or there's a new upstream maintainer found, which would also match the statement - there are no names named. (Or Linus changes his mind of course, but that's probably just a theoretical possibility).

(Disclaimer: Jiri is my team colleague)

Frankly, ridiculous social behaviour!

Posted Sep 10, 2025 18:44 UTC (Wed) by koverstreet (subscriber, #4296) [Link] (13 responses)

There's a reason we generally avoid adding to drama like this, especially in an official capacity that escalates the scope of drama from one project even wider; if you have to get involved, it helps to try to get informed first and look for ways to be constructive.

Otherwise, you're just blowing issues open even wider and forcing people to respond more publicly they otherwise would've wanted to.

So, now I have to respond...

The driver for the drama in the kernel, consistently, was just over getting bugfixes out: these were process issues. Specifically, Linux (and Ted) have repeatedly tried to dictate on what is and is not a critical bugfix, despite having no other involvement with bcachefs, not being informed (and explicitly not wanting to be informed) on QA processes, ignoring the severity of bugs - the list goes on.

It's dysfunctional and actively dangerous to have people dictating over process without being properly informed and not wanting to be informed (and it's not like I don't write solid commit messages and pull requests messages where relevant, or haven't been willing to discuss these issues), and I can't ship and support a filesystem without a functional release process. The buck stops with me on bcachefs bug reports, I'm the one who ensures that the code works for my users, and the drama has consistently been over bugfixes that were purely internal to bcachefs with no realistically conceivable impact to the rest of the kernel (we also have _very_ good automated testing and QA).

Trying to refocus on the technical, by myself and others, has repeatedly gotten nowhere; I'm going to stop short of saying here what the responses have been.

So, relations have broken down, but that doesn't mean I'm going to stop working or that users don't still need something more reliable; that is the message I get consistently from users and funders.

We still need something better.

So, I would _greatly_ appreciate it if we not escalate kernel drama until it takes over the entire community. Drama has a way of crowding out all the intelligent technical conversation; quieter, more thoughtful people step back and the loudest and angriest voices take over. I have already been through enough cycles of that...

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 7:37 UTC (Thu) by marcH (subscriber, #57642) [Link] (8 responses)

> So, now I have to respond...

No, you really didn't have to. Imagine your words are code. Would you tolerate so much duplication?

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 12:05 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (7 responses)

As far as I know, it is common practice for journalists to reach out for comments before talking about some event after having heard only one side.

LWN does not do this, you want to forbid writing a comment too when anyone else is allowed to comment?

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 12:32 UTC (Thu) by daroc (editor, #160859) [Link] (2 responses)

We do actually reach out for comments. Perhaps not as often as other publications, and generally not for brief items, but we do. On the other hand, we're lucky enough that the open-source community tends to have discussions in public, which means that for many stories we don't have to request comments to see how someone feels about it.

We used to indicate the difference behind quotes that came from publicly available sources and quotes that came from private sources with styling differences (the latter were not colored), but readers found that confusing, so now all the quotes get CSS colors.

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 18:43 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

You certainly did not reach out to me before putting my name there, and it wasn't a brief :)

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 18:53 UTC (Thu) by ferringb (subscriber, #20752) [Link]

I've no clue how y'all will manage the moderation going forward- and I'm not happy asking this question since I prefer "technical debates to death" on LWN as ellucidation of details of said technical....

We're not really in that state now, and you've got the mute statistics to know this better than my own annecdotal notes in regards to the percentages involved.

Consideration for a future post: how to keep LWN as 'LWN' rather than /.

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 18:00 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

> LWN does not do this, you want to forbid writing a comment too when anyone else is allowed to comment?

No idea where you got that from.

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 18:44 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

From here? https://lwn.net/Articles/1037592/

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 20:44 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

combined with your imagination?

Please stop here

Posted Sep 11, 2025 20:51 UTC (Thu) by jake (editor, #205) [Link]

this sub-thread does not look like it is going anywhere useful ... please stop ...

thanks,

jake

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 18:10 UTC (Thu) by tuna (guest, #44480) [Link] (3 responses)

"The driver for the drama in the kernel, consistently, was just over getting bugfixes out: these were process issues. Specifically, Linux (and Ted) have repeatedly tried to dictate on what is and is not a critical bugfix, despite having no other involvement with bcachefs, not being informed (and explicitly not wanting to be informed) on QA processes, ignoring the severity of bugs - the list goes on."

That is Linus T's job as maintainer and lead developer of Linux. He and nobody else gets to decide what is a critical bug fix. If you want to fork Linux that is perfectly OK, but then YOU are responsible for all of it.

"The buck stops with me on bcachefs bug reports, "

Not if you are part of Linux.

Frankly, ridiculous social behaviour!

Posted Sep 11, 2025 19:05 UTC (Thu) by koverstreet (subscriber, #4296) [Link] (2 responses)

> "The buck stops with me on bcachefs bug reports, "

Is there someone else responding to bcachefs bugs and supporting users I didn't know about? :)

Frankly, ridiculous social behaviour!

Posted Sep 12, 2025 17:21 UTC (Fri) by tuna (guest, #44480) [Link] (1 responses)

bcachefs users run the rest of Linux so everyone working on Linux is essentially supporting them. A lot of times you don't know the root cause of a bug, so I would assume people look at bug reports and then maybe determine that the bug is are caused by the bcachesfs system. But it seems like most bcachefs user reach out to you directly so that might not happen alot, but if bcachefs ever was included in something like RHEL then Red Hat etc. would of course support it.

Frankly, ridiculous social behaviour!

Posted Sep 12, 2025 17:50 UTC (Fri) by koverstreet (subscriber, #4296) [Link]

yeah, I don't throw code over a wall and walk away, my job isn't done until I know that my code is working as advertised for everyone running it :)

Stabilizing a filesystem requires doing a lot of what amounts of support - if you want to do it well and end up with something polished, easy to debug, and not janky, and get it done in a reasonable amount of time.

I spend a lot of time actively hunting down bug reports and data.

That does mean that I end up debugging issues with other subsystems, too...

The change itself makes sense

Posted Sep 10, 2025 16:10 UTC (Wed) by epa (subscriber, #39769) [Link] (4 responses)

The last sentence of the announcement is mean, but I can see why SuSE made the change. It makes more sense for bcachefs testers to get their kernels and utilities directly from the upstream maintainer. He can push out fixes whenever it makes sense for his users and not have to fight against the Linux kernel's release schedule. This seems more appropriate while the new filesystem is still being stabilized.

The change itself makes sense

Posted Sep 10, 2025 16:17 UTC (Wed) by koverstreet (subscriber, #4296) [Link] (3 responses)

As of 6.16, it's looking quite stable. We're getting down to the dregs of the open bugs.

The kernel release process was, unfortunately, far too contentious, but that ship has sailed now.

Let's please not screw over users any more than we already have...

The change itself makes sense

Posted Sep 12, 2025 20:27 UTC (Fri) by lkundrak (subscriber, #43452) [Link] (2 responses)

> Let's please not screw over users any more than we already have...

Your use of use royal we is disingenuous here. *You* sir screwed over the users.

The change itself makes sense

Posted Sep 12, 2025 20:46 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> Your use of use royal we is disingenuous here. *You* sir screwed over the users.

Your use of the singular is extremely disingenuous.

The change itself makes sense

Posted Sep 12, 2025 21:02 UTC (Fri) by corbet (editor, #1) [Link]

Can we agree that this kind of stuff has gone far enough? Speaking to everybody in the thread, let's please just stop throwing mudballs at each other, OK?

Can we all please communicate before making big decisions like this?

Posted Sep 10, 2025 16:15 UTC (Wed) by koverstreet (subscriber, #4296) [Link] (18 responses)

I just got linked a Debian bug tracker thread where they were talking about doing the same thing: distros, can you please at least try to check with upstream and actual users before doing anything big?

bcachefs in 6.16 is solid; we did an amazing job of closing bugs before the 6.16 release, and bug reports have been quite (and I'm in regular communication with a lot of people).

Since the 6.16 release, I don't think there's been a single critical bug (= filesystem offline) that we absolutely have to get a fix out for: there's bugfixes in my master branch, but the worst I've seen is a bug where we launch more expensive repair than we need to - we still repair and mount automatically with zero user intervention.

Besides that, it's been fixes for performance bugs and a ton of test dashboard stuff and minor nuts: there's really nothing critical, so it's totally fine for users to stick with what's in 6.16 for a release. If there was something critical we needed to get out, you'd be hearing from me.

I've got a couple things I'm trying to get finished up before the DKMS release, but it's coming soon.

Distros: _please_ think this through, don't just yank it without communicating or formulating a plan. No action is totally fine for now; no need to rush.

Can we all please communicate before making big decisions like this?

Posted Sep 10, 2025 18:17 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (1 responses)

As it is now, it is not clear how future bugs will be resolved. And as solid as it is, it is likely to have bugs because it is software. Distributions should consider how to be able to fix bugs that will discovered in the future. The alternative is to keep it, and in case of a potential serious bug, stop supporting it. But this is not practical for a file system.

BTW: Not having the original module in the built will slightly simplify deploying a dkms module.

Can we all please communicate before making big decisions like this?

Posted Sep 10, 2025 18:46 UTC (Wed) by koverstreet (subscriber, #4296) [Link]

There's another option, which is just to coordinate dropping it from the kernel config with shipping the DKMS version, to minimize disruption.

Like I said, this is still happening soon, it just hasn't been super urgent yet given all the data we're seeing on stability. There were also still some late back channel efforts to mediate, which unfortunately did not pan out.

Can we all please communicate before making big decisions like this?

Posted Sep 10, 2025 22:17 UTC (Wed) by paravoid (subscriber, #32869) [Link] (4 responses)

> distros, can you please at least try to check with upstream and actual users before doing anything big?

These are changes to the downstream Linux packages (src:linux in Debian). Upstream for Linux is the upstream kernel community, i.e. kernels shipped by kernel.org, ultimately maintained by Linus Torvalds. Upstream has declared the filesystem as "EXPERIMENTAL", and more recently as "externally maintained", i.e. not maintained by them. Updates have stopped flowing in the code they're shipping. So Debian -and from what I can tell from the article, openSUSE- are, in fact, following upstream's wishes here. The upstream change is precisely the trigger for the downstream changes.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 7:21 UTC (Thu) by taladar (subscriber, #68407) [Link] (3 responses)

Distros have a long history of including changes in the kernel (and other packages) that are not sourced directly from their immediate upstream but the ultimate upstream project or even changes they themselves created. It is not as if they are bound by some long tradition of shipping exactly the version of their immediate upstream project, especially for the kernel.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 8:31 UTC (Thu) by interalia (subscriber, #26615) [Link]

That's true, but they don't also have to volunteer to integrate an external bcachefs either, when it's still a small minority filesystem. If somehow ext4 or btrfs became an externally maintained filesystem then yes, the distros probably would integrate support due to the huge existing installed base that would break if they got removed. But I don't think the bcachefs userbase would have the same weight.

I know Kent is posting above asking them not to remove, but as rahsulsundaram posted above this seemed inevitable. If upstreams Linus and Kent can't get on, I can understand if distro kernel maintainers are reluctant to put themselves in the same position as Linus where they might argue with Kent over what to include/not include in their kernel. Letting the bcachefs userbase interact with him directly for their fixes seems a safer bet to avoid aggravation. He gets the only outcome he accepts, which is to ship the code he wants without any intermediary decision.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 11:59 UTC (Thu) by paravoid (subscriber, #32869) [Link]

The point was that a third-party, author of an experimental, externally maintained patchset, and one that the package does NOT carry, has the expectation of being asked before changes are made to that package. That is neither a sensible nor a realistic expectation.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 13:10 UTC (Thu) by pizza (subscriber, #46) [Link]

> Distros have a long history of including changes in the kernel (and other packages) that are not sourced directly from their immediate upstream but the ultimate upstream project or even changes they themselves created. It is not as if they are bound by some long tradition of shipping exactly the version of their immediate upstream project, especially for the kernel.

It's also worth mentioning that there are countless examples of "maintained in name only" in Linux. [1] Even officially "unmaintained" stuff routinely lingers around for years without removal.

And then you have "actively maintained" stuff that sees constant churn and new (major) regressions every release cycle, and that's considered perfectly fine.

Point being, "externally maintained" is *meaningless* when it comes to perceived (or even *actual*) quality.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 8:48 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (8 responses)

Any distribution that ships bcachefs has to ensure some level of support for the users that install the distribution using this filesystem. *Of* *course* they are all going to drop bcachefs like a hot potato till its maintenance situation is resolved (and resolved with some insurances it will not degrade again, once burned twice shy). Any supplementary user that uses this filesystem because it is still available is a long term problem for the distribution that enables this installation.

That’s what playing by Linus’ rules buys you: free integration in all downstreams that trust Linus (ie every single major distribution). You would need to provide stellar value for any downstream to invest into some other integration path. Other integration paths are expensive to setup and maintain and at high risk of conflict with upstream kernel. Playing by the rules even if you don’t like the rules is the simplest path to adoption.

Remember that Suse is the most adventurous of mainstream distributions filesystem-wise and has paid the price for it many times. Others will be more conservative.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 11:44 UTC (Thu) by pizza (subscriber, #46) [Link] (7 responses)

> Any distribution that ships bcachefs has to ensure some level of support for the users that install the distribution using this filesystem. *Of* *course* they are all going to drop bcachefs like a hot potato till its maintenance situation is resolved

How long was reiserfs kept around after its primary author went to prison for literally commiting murder?

(answer: approximately forever, despite it being effectively dead upstream)

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 11:50 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (6 responses)

reiserfs was extremely painful because it was already widely used when its author went into prison. Thus it could not be dropped easily. Distributions will strive to avoid a repeat.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 11:54 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

>Thus it could not be dropped easily. Distributions will strive to avoid a repeat.

...by instead preemptively dropping things at the slightest sign of any turmoil?

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 12:07 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

Getting shown the way out by Linus is hardly “the slightest sign of any turmoil”. When you are a FAANG what upstream thinks hardly matters, you are rich enough to do whatever you like. When you are not a FAANG tearing up relationships has consequences.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 13:01 UTC (Thu) by pizza (subscriber, #46) [Link]

> When you are not a FAANG tearing up relationships has consequences.

...Linus and OpenSuSE are not FAANGs, so... thanks for making my point for me?

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 13:42 UTC (Thu) by koverstreet (subscriber, #4296) [Link]

Well, bcachefs is a massive project; there's a lot of priorities I have to balance, and relations with Linus is just one of many.

And I'm rich where it counts - community support. People have really been stepping up on DKMS and distro stuff, so that's all coming together quicker than I expected.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 15:42 UTC (Thu) by anselm (subscriber, #2796) [Link] (1 responses)

Also IIRC at that point Hans Reiser was no longer actually involved with the reiserfs that was widely deployed (especially on Suse). Instead, he spent most of his time working on reiser4, which, in the end, never really got anywhere not just because of the going-to-prison thing but also because it was perhaps a little too revolutionary to be a viable Linux file system.

Can we all please communicate before making big decisions like this?

Posted Sep 17, 2025 17:56 UTC (Wed) by anton (subscriber, #25547) [Link]

My impression was that reiser4 was treated with suspicion was that Reiser had discontinued support for reiserfs. The court and prison thing came soon after and did not help. Some people continued to work on it for a long time, not sure if they still are.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 11:12 UTC (Thu) by niner (guest, #26151) [Link] (1 responses)

Given your statement that bcachefs in 6.16 is solid which I read as "ready for users", I now wonder whether you still consider the consequences worth the escalation over that fsck/repair commit? It seems to me that if you had given in and waited for one more release, you'd now be in a situation where you have a stable product that reaches its potential users via the usual channels. Was it really worth losing this? I am also asking because I can see myself getting in such a situation and now wonder whether I could learn something here.

Can we all please communicate before making big decisions like this?

Posted Sep 11, 2025 13:36 UTC (Thu) by koverstreet (subscriber, #4296) [Link]

Yeah, I do - it wasn't just this one thing, there have been way too many arguments over pull request bugfixes.

Dealing with the distros directly is going to be a bit more work at first, but so far it's looking like much less drama. Debian also said they wouldn't flip off bcachefs in 6.17, so now we just need to get bcachefs-tools un-orphaned in Debian and then maybe we'll finally have bcachefs properly supported in Debian, too.

So timing wise this certainly worked out ok. With bcachefs stabilizing I actually have the bandwidth to focus on the distros, and that needed to happen at some point anyways.

At some point we can go start looking more at systemd integration stuff too; encryption passphrase handling, better degraded mode handling... no shortage of things to do.

bcachefs announcement on DKMS:

Posted Sep 11, 2025 23:30 UTC (Thu) by koverstreet (subscriber, #4296) [Link] (9 responses)

way to go, I typo'd the subject :)

https://lore.kernel.org/linux-bcachefs/yokpt2d2g2lluyomtq...

bcachefs announcement on DKMS:

Posted Sep 12, 2025 1:49 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (1 responses)

I know from other threads that I am not the only one that was using bcachefs on Chimera Linux.

bcachefs announcement on DKMS:

Posted Sep 12, 2025 3:51 UTC (Fri) by koverstreet (subscriber, #4296) [Link]

made a ton of progress on rebalance_v2 today :)

(after fun distro/DKMS work, heh)

I'm looking forward to finally putting all this drama behind us and having more time for coding.

bcachefs announcement on DKMS:

Posted Sep 13, 2025 16:56 UTC (Sat) by donald.buczek (subscriber, #112892) [Link] (6 responses)

Thanks, Kent.

Unfortunately, out-of-tree modules are still extremely inconvenient for us. We automatically build every kernel as soon as a new version tag appears in the Linux or stable Git repository, including rc kernels. We merge our (few) own patches (custom NFS authentication, NFS tracepoints, and minor details, plus our configuration). Sometimes this fails and we have to resolve the merge conflicts manually. But since these are our patches, we can do that ourselves. This way, we have every kernel immediately available when we want to test something new or think we need to update due to security issues. We don't have to wait for third parties to adapt their code to the changed kernel infrastructure.

I don't know how that would work with an out-of-tree module. We stopped trying to build ZFS with the kernel years ago. Now only Nvidia remains as a pain factor, but we only build that when necessary and then manually.

Furthermore, every source that we automatically integrate into our kernels would be an additional vector for introducing malicious code and bugs.

What I'm trying to say is that the current situation is very unfortunate because we are an example of a user who fundamentally rejects out-of-tree modules. Perhaps as motivation not to give up on bcachefs in the tree forever. I realize that no one can predict that at the moment and that it will be a long road at the very least.

bcachefs announcement on DKMS:

Posted Sep 13, 2025 17:14 UTC (Sat) by madscientist (subscriber, #16861) [Link] (5 responses)

My understanding is that DKMS is targeting exactly this pain point. Would that be sufficient, if available?

bcachefs announcement on DKMS:

Posted Sep 13, 2025 17:27 UTC (Sat) by donald.buczek (subscriber, #112892) [Link] (4 responses)

> My understanding is that DKMS is targeting exactly this pain point. Would that be sufficient, if available?

I don't know much about DKMS. But basically, it's a system for automatically rebuilding modules for new kernels, right? But if something relevant to the module has changed in the kernel's ABI or API, then this has to fail and you would have to wait for the module maintainer to reprogram it, no?

bcachefs announcement on DKMS:

Posted Sep 13, 2025 17:43 UTC (Sat) by koverstreet (subscriber, #4296) [Link] (3 responses)

I'll be handling that part - that's the easy part for me.

The interfaces that bcachefs uses are a lot less churny than they used to be, and I already have the CI infrastructure so I'll be able to automatically test on a variety of kernel versions, including tip of Linus's tree, so I'll be able to handle any issues well before you see them.

bcachefs announcement on DKMS:

Posted Sep 13, 2025 17:53 UTC (Sat) by donald.buczek (subscriber, #112892) [Link] (2 responses)

Am I correct in understanding that when my cronjob sees a new rc1 kernel tag in Linus' tree, a corresponding branch or tag will always already be available at https://evilpiepirate.org/git/bcachefs.git?

That would be great, even though I don't know how you do it. Something could still change at the last minute with rc1, which would require you to do some rework?

bcachefs announcement on DKMS:

Posted Sep 13, 2025 18:56 UTC (Sat) by koverstreet (subscriber, #4296) [Link] (1 responses)

I could try to set up something like that, if you're going to use it?

Set up a job to watch for new tags in Linus's tree, do a git merge with my branch and push to the CI.

What I had in mind though was making sure the DKMS version in bcachefs-tools builds and is tested on every release from Linus's tree - that'll be easy, and I'll definitely be doing that for all the DKMS users.

bcachefs announcement on DKMS:

Posted Sep 13, 2025 21:14 UTC (Sat) by donald.buczek (subscriber, #112892) [Link]

I can't really promise anything. There are so many things I plan to do, but in the end, I may not find the time.

I currently have 102 TB of unused space on a backup server and I was thinking of trying it out with bcachefs. There are a lot of files with a lot of hard links (more than ext4 allows) on these backup filesystems and with XFS, performance is an issue when deleting expired copies. Data checksums might be good too, as undetected errors accumulate due to the constant incremental backup and would never be replaced by fresh data.

Come to think of it, though, it wouldn't really matter if bcachefs wasn't available right away when an rc1 kernel comes out. Whether an rc kernel is ready a week or two later isn't really relevant. And we won't use rc kernels on out backup servers anyway. And with stable releases, conflicts should be the absolute exception anyway and usually won'tt require any manual adjustment work on your part.

To enable automation for consumers like us, it would only be necessary to clarify which tag or branch from your tree should be used for a specific kernel release. Perhaps the reference at the end of your CI could be created automatically, so that it wouldn't require any additional manual work?

On the other hand, you somehow have to do it for DKMS anyway, and maybe we should first take a closer look at whether we can use these DKMS releases.

However, as already mentioned, in addition to the added complexity during the build, there are other concerns with out-of-tree modules: security, continuity, additional dependencies...