10 ms·

Bcachefs removed from the mainline kernel

239 points by Bogdanp 1y ago

patrakov 1y ago
The end result is still positive. Before the mainline submission, Bcachefs could not be DKMSed, as it relied on changes in other subsystems, as opposed to just additions, so you had to compile your own kernel. Now, it is available as something that can be compiled as a module for any recent-enough third-party kernel.
- kouteiheika 1y ago
  ...for now. The policy of Linux is that they don't care about external modules/drivers at all, so once they start removing whatever bcachefs needs because no in-tree filesystem uses it we'll be back to a world of pain. (Unless they make an exception; they sure don't make one for ZFS.)
  - ThatPlayer 1y ago
    It doesn't seem to have been completely removed: Bcachefs is still listed among the MAINTAINERS: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/MAINTAINERS?id=f2c61db29f27 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... where only the references to removed files were removed. For now
  - alphabetag675 1y ago
    That's patently untrue. They do not remove stuff, they just keep changing the APi which means that the modules need to keep evolving.
    - matja 1y ago
      does removing EXPORT_SYMBOL(__kernel_fpu_end); [0] - which broke ZFS, count as removing stuff or changing the API? AFAIK that change didn't add functionality or fix any existing issues, other than breaking ZFS - which GKH was absolutely fine with, dismissing several requests for it to be reverted, stating the "policy": [1] > Sorry, no, we do not keep symbols exported for no in-kernel users. [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.16.9&id=12209993e98c5fa1855c467f22a24e3d5b8be205 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.com/ https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.co...
      - mnau 1y ago
        Quite reasonable policy. Add a second line too: > Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly? Why would you accommodate someone who explicitly went out of their way to not accommodate you? It took many conflicts with bcachefs developer to reach this state. Olive branch has been extended again and again...
        timeon 1y ago
        Not sure if the thread is about how reasonable is the policy or if it is patently untrue that things get removed.
        matja 1y ago
        "accommodate" in this instance would have been accomplished by doing nothing. The Linux kernel developers actively made this change.
        mnau 1y ago
        Doing "nothing" in this case seems to be leaving technical debt in a code. I am not kernel developer, but less exposed API/functions is nearly always better. The removed comment of function even starts with: Careful: __kernel_fpu_begin/end() must be called with
        nubinetwork 1y ago
        Sun doesn't exist anymore, and while openzfs is compatible with older versions of any of Oracle's life support Solaris, it's not the same ecosystem. Yes, the same licensing issues still exist, but openzfs has been developed by LLNL for Linux ever since it was called "zfs for Linux".
        capitol_ 1y ago
        If that ecosystem have changed their values/opinions on that topic, the it wouldn't be an impossible task to dual-license it with a compatible license. (Hard and tedious work, but not impossible).
    - AndrewDavis 1y ago
      That's all a matter of perspective. Is moving a symbol from EXPORT_SYMBOL(some_fun) to EXPORT_SYMBOL_GPL(some_func) actually changing the API? Nope, the API is exactly the same as it was before, it's just changed who is allowed to use it. From the perspective of an out of tree module that isn't GPL you have removed stuff. I'm honestly not sure how one outside the kernel community could construe that as not removing something.
      - happymellon 1y ago
        They could always move to a compatible license? No, it was always designed to be hostile to Linux from the outset. It's a project that doesn't want to interoperability with Linux so I'm not entirely sure why you think the Linux folks should maintain an API for them.
        Sanzig 1y ago
        You are ascribing motives to the OpenZFS project that aren't there. Sun was the one that licensed it CDDL, and OpenZFS is a fork that was created when Oracle bought Sun and decided to close source ZFS. Oracle has zero involvement with OpenZFS. Since the pre-fork code is from Sun, Oracle owns the copyright, and they won't re-license it. The idea that the OpenZFS team wants CDDL out of spite for Linux is an absurd conspiracy theory. Their hands are tied - I'm sure they'd move to a compatible license if they could, but they can't.
        p_l 1y ago
        CDDL ensures OpenZFS can be used for not just Linux, and prevents patent-based attacks (which have been used against GPLv2 code reuse in the past). So the OpenZFS team is not exactly interested in moving to GPLv2, because it would break multiple platforms.
        Sanzig 1y ago
        I doubt the OpenZFS team would move to GPLv2 if they were able to relicense to anything they wanted. Given their close association with FreeBSD, BSD-2 or a similar permissive license wouldn't shock me. But it's an academic exercise anyway, since it seems Oracle has no intention of allowing them to relicense.
- aragilar 1y ago
  But presumably if said changes preventing DKMS usage were reasonable they would have been merged anyway independent of bcachefs, and likely with less drama and disruption? I'm not suggesting that there aren't some silver linings to the cloud, but it doesn't seem like the result is anywhere near neutral (let alone positive) for anyone involved.
  - deleted 1y ago
    [deleted]
  - arghwhat 1y ago
    Yes and no - the kernel interfaces only reflect what the kernel itself needs. It doesn't to my knowledge maintain interfaces for the purpose of enabling out-of-tree modules. Changes would therefore need to be an improvement for in-tree drivers, and not merely something for an out-of-tree driver.
- dev_l1x_be 1y ago
  Was this the reason they removed it from mainline?
  - masklinn 1y ago
    No, the reason they removed it from mainline is that the maintainer has proved (yet again) incapable of working with others if they can't get their way: https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=r...
  - odo1242 1y ago
    No, it was a conflict between Kent Overstreet and Linus Torvalds over Kent Overstreet constantly submitting patches too late in the merge window.
    - charcircuit 1y ago
      Submitting bug fixes for release candidates is not too late in the merge window. That's why they are a release candidate and not the final release.
      - sc68cal 1y ago
        They were not bug fixes
        rurban 1y ago
        They were repair fixes to fix a corrupted filesystem. Which is allowed in a merge window. XFS did the very same before. Ken's code was just a lot.
      - cwillu 1y ago
        Slipping feature code in with bug fixes is a abuse of good faith.
        1y ago
tarruda 1y ago
I hope it eventually comes back once it is more stable. Would be great to have an in kernel alternative to ZFS for parity RAID.
- masklinn 1y ago
  It was not removed due to instability but due to the maintainer’s inability to respect guidelines set by others when they don’t personally agree. This is not the first project for which this was an issue, and said maintainer has shown no will to alter their behaviour before or since.
  - akimbostrawman 1y ago
    He justified breaking the guidelines to address critical issues. one can hope these kind of problems would not happen that frequently in a stable project, besides it is still experimental.
    - mrweasel 1y ago
      My take away from trying to follow the discussion on the kernel mailing list was that the Bcachefs developer want to work in a certain way, that Linus does not think that fit in with the rest of the kernel (to put it mildly). Having Bcachefs in the kernel certainly helps with adoption, but I can't help thinking that a kernel module might be more inline with the development process that Bcachefs wants. The underlying problem might have been importing Bcachefs into the mainline kernel to early in it's life cycle.
      - jeltz 1y ago
        No, this is a pure people problem which would have happened no matter the state of Bcachefs. Kent refuses to respect other people's time and rules since that would require him to change how he works.
        typpilol 1y ago
globalhsbc 1y ago
[dead]
mnau 1y ago
I don't get why Linus just didn't tell bcachefs developer to take a hike. He is BDFL. No, these changes do not belong into this part of our release window. No pull. End of discussion. Instead he always talked and caved and pulled. And of course situation repeated, as they do...
- arccy 1y ago
  this is telling him to take a hike?
  - pluto_modadic 1y ago
    to take a hike sooner*
  - mnau 1y ago
    I meant not accepting pulls during rc phase, not kick him out. Instead he always sighed and accepted new features alongside with bug fixes.
  - tpetry 1y ago
    Linus told him some time ago to take a hile. Kent was blocked from one (or two?) previous merge windows long ago to behave like expected from someone contributing to Linux. He didnt change. It was drama since he was first added to the kernel. This was really not the first issue.
- aidenn0 1y ago
  A manager must trust those people who are closer to the problem to make such decisions. When, in hindsight, it looks like the trust is habitually abused, the scalable solution isn't to micromanage that person, it's to fire them.
- bombcar 1y ago
  Linus did tell him to take a hike, and this is exactly what this is. Perhaps as BDFL he let it slip a few too many times, but that's generally the way you want to go - as a leader, you want to trust your subordinates are doing the right thing; which means that you'll get burned a few times until you have to take action (like this). The only other option makes you into a micromanager, which doesn't scale.
deleted 1y ago
[deleted]
fer 1y ago
I have high hopes for bcachefs, but so far the benchmarks[0] are a quite disappointing. I understand it'll have overhead since it does many things, but I'd expect it to perform closer to btrfs or zfs, but it's consistently abysmal (which affects zfs at times, too). [0] https://www.phoronix.com/review/linux-617-filesystems https://www.phoronix.com/review/linux-617-filesystems
- BearOso 1y ago
  Those benchmarks were messed up. Notice bcachefs is the only one using 512b block size. That's going to massively increase overhead.
  - Ardren 1y ago
    > I very much doubt that's the main issue - the multithreaded sqlite performance makes me wonder if something's up with our fsync performance. I'll wait to see the results with the DKMS version, and if the numbers are still bad I'll have to see if I can replicate it and start digging. https://www.phoronix.com/forums/forum/software/general-linux-open-source/1578604-linux-6-17-file-system-benchmarks-including-openzfs-bcachefs/page3#post1578655 https://www.phoronix.com/forums/forum/software/general-linux...
- barrkel 1y ago
  It's hard to take those benchmarks too seriously. ZFS, btrfs and I guess bcachefs - which I've never used and don't have any opinion on - do things XFS and EXT4 don't and can't do. I know more about ZFS than the others. It wasn't specified here whether ZFS had ashift=9 or 12; it tries to auto-detect, but that can go wrong. ashift=9 means ZFS is doing physical I/O in 512 bytes, which will be an emulation mode for the nvme. Maybe it was ashift=12. But you can't tell. Secondly, ZFS defaults to a record size of 128k. Write a big file and it's written in "chunks" of 128k size. If you then run a random read/write I/O benchmark on it with a 4k block size, ZFS is going to be reading and writing 128k for every 4k of I/O. That's a huge amplification factor. If you're using ZFS for a load which resembles random block I/O, you'll want to tune the recordsize to the app I/O. And ZFS makes this easy, since child filesystem creation is trivially cheap and the recordsize can be tuned per filesystem. And then there's the stuff things like ZFS does that XFS / EXT4 doesn't. For example, taking snapshots every 5 minutes (they're basically free), doing streaming incremental snapshot backups, snapshot cloning and so on - without getting into RAID flexibility.
wizardforhire 1y ago
I was one week away from setting up a new cluster and was all all in on bcachefs, drama be damned … that was until this[1] Bcachefs is exciting on paper, but even just playing around there are some things that are just untenable imho. Time has proven that the stability of a project stems from the stability of the teams and culture behind it. As such the numbers don’t lie and unless it can be at parity with existing filesystems I can’t be bothered to forgive the misgivings. I’m looking forward to the day when bcachefs matures… if ever, as it is exciting. Also if something has changed in the last year I’d love to hear about it! I just haven’t found anything compelling enough yet to risk my time bsing around with it atm. [1] https://youtube.com/watch?v=_RKSaY4glSc&pp=ygUZTGludXMgZmlsZXN5c3RlbSBzaG9vdG91dA%3D%3D https://youtube.com/watch?v=_RKSaY4glSc&pp=ygUZTGludXMgZmlsZ...
maxlin 1y ago
At least some of the OSS drama still is just purely code-based these days... The dev acted out of line for kernel development, even if _kind_ of understandable (like with the recovery tool), but still in a way that would set a bad precedent for the kernel, so this appears to be good judgement from Linus. Hope the best for Bcachefs's future
exploderate 1y ago
The one line "article" on lwn.net has a link to this email: From: Kent Overstreet @ 2025-09-11 23:19 UTC As many of you are no doubt aware, bcachefs is switching to shipping as a DKMS module. Once the DKMS packages are in place very little should change for end users, but we've got some work to do on the distribution side of things to make sure things go smoothly. Good news: ... https://lore.kernel.org/linux-bcachefs/yokpt2d2g2lluyomtqrdvmkl3amv3kgnipmenobkpgx537kay7@xgcgjviv3n7x/T/ https://lore.kernel.org/linux-bcachefs/yokpt2d2g2lluyomtqrdv...
- doublerabbit 1y ago
  > Once the DKMS packages are in place very little should change for end users Doesn't that mean I now have to enroll the MOK key on all my work workstations that use secure boot? If so that's a huge PITA on over 200 machines. As like with the NVIDIA driver you can't automate the facility.
  - deleted 1y ago
    [deleted]
  - yomismoaqui 1y ago
    Not to troll, I'm asking in good faith Is this filesystem stable enough for deploying on 200 production machines? From a cursory look I get things like this: https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesystem-stability-controversy/ https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesys...
    - bravetraveler 1y ago
      I have to constantly adjust my comfort level regarding what 'production' means. Consider the prep conditions, or 'prod', for your typical Chef or Butcher! Anyway, fair question IMO. Another point I'd like to make... migrating away from this filesystem, disabling secure boot, or leaning into key enrollment would be fine. Dealer's choice. The 'forced interaction' for enrollment absolutely presents a hurdle. That said: this wouldn't be the first time I've used 'expect' to use the management interface at scale. 200 is a good warm up. The easy way is to... opt out of secure boot. Get an exception if your compliance program demands it [and tell them about this module, too]. Don't forget your 'Business Continuity/Disaster Recovery' of... everything. Documents, scheduled procedures, tooling, whatever. Again, though, stability is a fair question/point. Filesystems and storage are cursed. That would be my concern before 'how do I scale', which comparatively, is a dream.
Jahez1219 1y ago
[flagged]
danw1979 1y ago
As a long time sponsor of Kent's on Patreon - $10 a month since 2018, $790 total - I've found this bcachefs debacle really depressing. I'm not even a bcachefs user, but I use ZFS extensively and I _really_ wanted Linux to get a native, modern COW filesystem that was unencumbered by the crappy corporate baggage that ZFS has. In the comments on HN around any bcachefs news (including this one) there are always a couple throwaway accounts bleating the same arguments - sounding like the victim - that Kent frequently uses. To Kent, if you're reading this: From a long time (and now former) sponsor: if these posts are actually from you, please stop. Also, it's time for introspection and to think how you could have handled this situation better, to avoid having disappointed those who have sponsored you financially for years. Yes, there are some difficult and flawed people maintaining the kernel, not least of which Linus himself, but you knew that when you started. I hope bcachefs will have a bright future, but the ball is very clearly in your court. This is your problem to fix. (I'm Daniel Wilson, subscription started 9th August 2018, last payment 1st Feb 2025)
- deleted 1y ago
  [deleted]
- spoaceman7777 1y ago
  What about btrfs? Seems to tick all of the boxes in regard to what you're looking for, and its mature enough that major linux distros are shipping with it as the default filesystem.
  - Macha 1y ago
    I think a lot of people interested in bcachefs were people who had lost faith in btrfs.
  - pfexec 1y ago
    Because every time btrfs is mentioned, 5 more people come out of the woodwork saying that it irreparably lost all their data. Sorry but there's just too many stories for it to be mere coincidences. Your statement is misleading. No one is using btrfs on servers. Debian and Ubuntu use ext4 by default. RHEL removed support for btrfs long ago, and it's not coming back: > Red Hat will not be moving Btrfs to a fully supported feature. It was fully removed in Red Hat Enterprise Linux 8.
bagxrvxpepzn 1y ago
Bcachefs comes off as a vanity project, as most open source software seems to be. The public rationale for it also strongly projects NIH. Therefore, its demise as everyone comes to grips with that is not very surprising. Hopefully this development serves to inoculate the kernel community against future wastes of resources. Perhaps the vetting process will become more rigorous before big merges like this.
charcircuit 1y ago
It's sad that it came with this, but in the end Linus and Kent had different ideas on how distribution of fixes should work so it makes sense that we have reached a situation where Kent controls the distribution frequency of the file system.
lesser-shadow 1y ago
[dead]
theLegionWithin 1y ago
good riddance
ErichLoew 1y ago
I use BTRFS, ZFS and BCACHEFS --> Recompiling ZFS for LATEST kernels is sometimes tricky. --> BTRFS and BCACHEFS are integral components of the kernel, hence their usage in combination with recompiling LATEST kernels is really a charm. And now ... BCACHEFS (like ZFS) is as well externalized, likely. --> I'm just shocked. --> And I still hope that all goes Best and BCACHEFS keeps staying in kernel.

239 points by Bogdanp 1y ago

The end result is still positive. Before the mainline submission, Bcachefs could not be DKMSed, as it relied on changes in other subsystems, as opposed to just additions, so you had to compile your own kernel. Now, it is available as something that can be compiled as a module for any recent-enough third-party kernel.

kouteiheika 1y ago
...for now. The policy of Linux is that they don't care about external modules/drivers at all, so once they start removing whatever bcachefs needs because no in-tree filesystem uses it we'll be back to a world of pain. (Unless they make an exception; they sure don't make one for ZFS.)
- ThatPlayer 1y ago
  It doesn't seem to have been completely removed: Bcachefs is still listed among the MAINTAINERS: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/MAINTAINERS?id=f2c61db29f27 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... where only the references to removed files were removed. For now
- alphabetag675 1y ago
  That's patently untrue. They do not remove stuff, they just keep changing the APi which means that the modules need to keep evolving.
  - matja 1y ago
    does removing EXPORT_SYMBOL(__kernel_fpu_end); [0] - which broke ZFS, count as removing stuff or changing the API? AFAIK that change didn't add functionality or fix any existing issues, other than breaking ZFS - which GKH was absolutely fine with, dismissing several requests for it to be reverted, stating the "policy": [1] > Sorry, no, we do not keep symbols exported for no in-kernel users. [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.16.9&id=12209993e98c5fa1855c467f22a24e3d5b8be205 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.com/ https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.co...
    - mnau 1y ago
      Quite reasonable policy. Add a second line too: > Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly? Why would you accommodate someone who explicitly went out of their way to not accommodate you? It took many conflicts with bcachefs developer to reach this state. Olive branch has been extended again and again...
      - timeon 1y ago
        Not sure if the thread is about how reasonable is the policy or if it is patently untrue that things get removed.
      - matja 1y ago
        "accommodate" in this instance would have been accomplished by doing nothing. The Linux kernel developers actively made this change.
        mnau 1y ago
        Doing "nothing" in this case seems to be leaving technical debt in a code. I am not kernel developer, but less exposed API/functions is nearly always better. The removed comment of function even starts with: Careful: __kernel_fpu_begin/end() must be called with
      - nubinetwork 1y ago
        Sun doesn't exist anymore, and while openzfs is compatible with older versions of any of Oracle's life support Solaris, it's not the same ecosystem. Yes, the same licensing issues still exist, but openzfs has been developed by LLNL for Linux ever since it was called "zfs for Linux".
        capitol_ 1y ago
        If that ecosystem have changed their values/opinions on that topic, the it wouldn't be an impossible task to dual-license it with a compatible license. (Hard and tedious work, but not impossible).
  - AndrewDavis 1y ago
    That's all a matter of perspective. Is moving a symbol from EXPORT_SYMBOL(some_fun) to EXPORT_SYMBOL_GPL(some_func) actually changing the API? Nope, the API is exactly the same as it was before, it's just changed who is allowed to use it. From the perspective of an out of tree module that isn't GPL you have removed stuff. I'm honestly not sure how one outside the kernel community could construe that as not removing something.
    - happymellon 1y ago
      They could always move to a compatible license? No, it was always designed to be hostile to Linux from the outset. It's a project that doesn't want to interoperability with Linux so I'm not entirely sure why you think the Linux folks should maintain an API for them.
      - Sanzig 1y ago
        You are ascribing motives to the OpenZFS project that aren't there. Sun was the one that licensed it CDDL, and OpenZFS is a fork that was created when Oracle bought Sun and decided to close source ZFS. Oracle has zero involvement with OpenZFS. Since the pre-fork code is from Sun, Oracle owns the copyright, and they won't re-license it. The idea that the OpenZFS team wants CDDL out of spite for Linux is an absurd conspiracy theory. Their hands are tied - I'm sure they'd move to a compatible license if they could, but they can't.
        p_l 1y ago
        CDDL ensures OpenZFS can be used for not just Linux, and prevents patent-based attacks (which have been used against GPLv2 code reuse in the past). So the OpenZFS team is not exactly interested in moving to GPLv2, because it would break multiple platforms.
        Sanzig 1y ago
        I doubt the OpenZFS team would move to GPLv2 if they were able to relicense to anything they wanted. Given their close association with FreeBSD, BSD-2 or a similar permissive license wouldn't shock me. But it's an academic exercise anyway, since it seems Oracle has no intention of allowing them to relicense.
aragilar 1y ago
But presumably if said changes preventing DKMS usage were reasonable they would have been merged anyway independent of bcachefs, and likely with less drama and disruption? I'm not suggesting that there aren't some silver linings to the cloud, but it doesn't seem like the result is anywhere near neutral (let alone positive) for anyone involved.
- deleted 1y ago
  [deleted]
- arghwhat 1y ago
  Yes and no - the kernel interfaces only reflect what the kernel itself needs. It doesn't to my knowledge maintain interfaces for the purpose of enabling out-of-tree modules. Changes would therefore need to be an improvement for in-tree drivers, and not merely something for an out-of-tree driver.
dev_l1x_be 1y ago
Was this the reason they removed it from mainline?
- masklinn 1y ago
  No, the reason they removed it from mainline is that the maintainer has proved (yet again) incapable of working with others if they can't get their way: https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=r...
- odo1242 1y ago
  No, it was a conflict between Kent Overstreet and Linus Torvalds over Kent Overstreet constantly submitting patches too late in the merge window.
  - charcircuit 1y ago
    Submitting bug fixes for release candidates is not too late in the merge window. That's why they are a release candidate and not the final release.
    - sc68cal 1y ago
      They were not bug fixes
      - rurban 1y ago
        They were repair fixes to fix a corrupted filesystem. Which is allowed in a merge window. XFS did the very same before. Ken's code was just a lot.
    - cwillu 1y ago
      Slipping feature code in with bug fixes is a abuse of good faith.
      - 1y ago

tarruda 1y ago

I hope it eventually comes back once it is more stable. Would be great to have an in kernel alternative to ZFS for parity RAID.

masklinn 1y ago
It was not removed due to instability but due to the maintainer’s inability to respect guidelines set by others when they don’t personally agree. This is not the first project for which this was an issue, and said maintainer has shown no will to alter their behaviour before or since.
- akimbostrawman 1y ago
  He justified breaking the guidelines to address critical issues. one can hope these kind of problems would not happen that frequently in a stable project, besides it is still experimental.
  - mrweasel 1y ago
    My take away from trying to follow the discussion on the kernel mailing list was that the Bcachefs developer want to work in a certain way, that Linus does not think that fit in with the rest of the kernel (to put it mildly). Having Bcachefs in the kernel certainly helps with adoption, but I can't help thinking that a kernel module might be more inline with the development process that Bcachefs wants. The underlying problem might have been importing Bcachefs into the mainline kernel to early in it's life cycle.
    - jeltz 1y ago
      No, this is a pure people problem which would have happened no matter the state of Bcachefs. Kent refuses to respect other people's time and rules since that would require him to change how he works.
      - typpilol 1y ago

globalhsbc 1y ago

[dead]

mnau 1y ago

I don't get why Linus just didn't tell bcachefs developer to take a hike. He is BDFL. No, these changes do not belong into this part of our release window. No pull. End of discussion. Instead he always talked and caved and pulled. And of course situation repeated, as they do...

arccy 1y ago
this is telling him to take a hike?
- pluto_modadic 1y ago
  to take a hike sooner*
- mnau 1y ago
  I meant not accepting pulls during rc phase, not kick him out. Instead he always sighed and accepted new features alongside with bug fixes.
- tpetry 1y ago
  Linus told him some time ago to take a hile. Kent was blocked from one (or two?) previous merge windows long ago to behave like expected from someone contributing to Linux. He didnt change. It was drama since he was first added to the kernel. This was really not the first issue.
aidenn0 1y ago
A manager must trust those people who are closer to the problem to make such decisions. When, in hindsight, it looks like the trust is habitually abused, the scalable solution isn't to micromanage that person, it's to fire them.
bombcar 1y ago
Linus did tell him to take a hike, and this is exactly what this is. Perhaps as BDFL he let it slip a few too many times, but that's generally the way you want to go - as a leader, you want to trust your subordinates are doing the right thing; which means that you'll get burned a few times until you have to take action (like this). The only other option makes you into a micromanager, which doesn't scale.

deleted 1y ago

[deleted]

fer 1y ago

I have high hopes for bcachefs, but so far the benchmarks[0] are a quite disappointing. I understand it'll have overhead since it does many things, but I'd expect it to perform closer to btrfs or zfs, but it's consistently abysmal (which affects zfs at times, too). [0] https://www.phoronix.com/review/linux-617-filesystems https://www.phoronix.com/review/linux-617-filesystems

BearOso 1y ago
Those benchmarks were messed up. Notice bcachefs is the only one using 512b block size. That's going to massively increase overhead.
- Ardren 1y ago
  > I very much doubt that's the main issue - the multithreaded sqlite performance makes me wonder if something's up with our fsync performance. I'll wait to see the results with the DKMS version, and if the numbers are still bad I'll have to see if I can replicate it and start digging. https://www.phoronix.com/forums/forum/software/general-linux-open-source/1578604-linux-6-17-file-system-benchmarks-including-openzfs-bcachefs/page3#post1578655 https://www.phoronix.com/forums/forum/software/general-linux...
barrkel 1y ago
It's hard to take those benchmarks too seriously. ZFS, btrfs and I guess bcachefs - which I've never used and don't have any opinion on - do things XFS and EXT4 don't and can't do. I know more about ZFS than the others. It wasn't specified here whether ZFS had ashift=9 or 12; it tries to auto-detect, but that can go wrong. ashift=9 means ZFS is doing physical I/O in 512 bytes, which will be an emulation mode for the nvme. Maybe it was ashift=12. But you can't tell. Secondly, ZFS defaults to a record size of 128k. Write a big file and it's written in "chunks" of 128k size. If you then run a random read/write I/O benchmark on it with a 4k block size, ZFS is going to be reading and writing 128k for every 4k of I/O. That's a huge amplification factor. If you're using ZFS for a load which resembles random block I/O, you'll want to tune the recordsize to the app I/O. And ZFS makes this easy, since child filesystem creation is trivially cheap and the recordsize can be tuned per filesystem. And then there's the stuff things like ZFS does that XFS / EXT4 doesn't. For example, taking snapshots every 5 minutes (they're basically free), doing streaming incremental snapshot backups, snapshot cloning and so on - without getting into RAID flexibility.

wizardforhire 1y ago

I was one week away from setting up a new cluster and was all all in on bcachefs, drama be damned … that was until this[1] Bcachefs is exciting on paper, but even just playing around there are some things that are just untenable imho. Time has proven that the stability of a project stems from the stability of the teams and culture behind it. As such the numbers don’t lie and unless it can be at parity with existing filesystems I can’t be bothered to forgive the misgivings. I’m looking forward to the day when bcachefs matures… if ever, as it is exciting. Also if something has changed in the last year I’d love to hear about it! I just haven’t found anything compelling enough yet to risk my time bsing around with it atm. [1] https://youtube.com/watch?v=_RKSaY4glSc&pp=ygUZTGludXMgZmlsZXN5c3RlbSBzaG9vdG91dA%3D%3D https://youtube.com/watch?v=_RKSaY4glSc&pp=ygUZTGludXMgZmlsZ...

maxlin 1y ago

At least some of the OSS drama still is just purely code-based these days... The dev acted out of line for kernel development, even if _kind_ of understandable (like with the recovery tool), but still in a way that would set a bad precedent for the kernel, so this appears to be good judgement from Linus. Hope the best for Bcachefs's future

exploderate 1y ago

The one line "article" on lwn.net has a link to this email: From: Kent Overstreet @ 2025-09-11 23:19 UTC As many of you are no doubt aware, bcachefs is switching to shipping as a DKMS module. Once the DKMS packages are in place very little should change for end users, but we've got some work to do on the distribution side of things to make sure things go smoothly. Good news: ... https://lore.kernel.org/linux-bcachefs/yokpt2d2g2lluyomtqrdvmkl3amv3kgnipmenobkpgx537kay7@xgcgjviv3n7x/T/ https://lore.kernel.org/linux-bcachefs/yokpt2d2g2lluyomtqrdv...

doublerabbit 1y ago
> Once the DKMS packages are in place very little should change for end users Doesn't that mean I now have to enroll the MOK key on all my work workstations that use secure boot? If so that's a huge PITA on over 200 machines. As like with the NVIDIA driver you can't automate the facility.
- deleted 1y ago
  [deleted]
- yomismoaqui 1y ago
  Not to troll, I'm asking in good faith Is this filesystem stable enough for deploying on 200 production machines? From a cursory look I get things like this: https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesystem-stability-controversy/ https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesys...
  - bravetraveler 1y ago
    I have to constantly adjust my comfort level regarding what 'production' means. Consider the prep conditions, or 'prod', for your typical Chef or Butcher! Anyway, fair question IMO. Another point I'd like to make... migrating away from this filesystem, disabling secure boot, or leaning into key enrollment would be fine. Dealer's choice. The 'forced interaction' for enrollment absolutely presents a hurdle. That said: this wouldn't be the first time I've used 'expect' to use the management interface at scale. 200 is a good warm up. The easy way is to... opt out of secure boot. Get an exception if your compliance program demands it [and tell them about this module, too]. Don't forget your 'Business Continuity/Disaster Recovery' of... everything. Documents, scheduled procedures, tooling, whatever. Again, though, stability is a fair question/point. Filesystems and storage are cursed. That would be my concern before 'how do I scale', which comparatively, is a dream.

Jahez1219 1y ago

[flagged]

danw1979 1y ago

As a long time sponsor of Kent's on Patreon - $10 a month since 2018, $790 total - I've found this bcachefs debacle really depressing. I'm not even a bcachefs user, but I use ZFS extensively and I _really_ wanted Linux to get a native, modern COW filesystem that was unencumbered by the crappy corporate baggage that ZFS has. In the comments on HN around any bcachefs news (including this one) there are always a couple throwaway accounts bleating the same arguments - sounding like the victim - that Kent frequently uses. To Kent, if you're reading this: From a long time (and now former) sponsor: if these posts are actually from you, please stop. Also, it's time for introspection and to think how you could have handled this situation better, to avoid having disappointed those who have sponsored you financially for years. Yes, there are some difficult and flawed people maintaining the kernel, not least of which Linus himself, but you knew that when you started. I hope bcachefs will have a bright future, but the ball is very clearly in your court. This is your problem to fix. (I'm Daniel Wilson, subscription started 9th August 2018, last payment 1st Feb 2025)

deleted 1y ago
[deleted]
spoaceman7777 1y ago
What about btrfs? Seems to tick all of the boxes in regard to what you're looking for, and its mature enough that major linux distros are shipping with it as the default filesystem.
- Macha 1y ago
  I think a lot of people interested in bcachefs were people who had lost faith in btrfs.
- pfexec 1y ago
  Because every time btrfs is mentioned, 5 more people come out of the woodwork saying that it irreparably lost all their data. Sorry but there's just too many stories for it to be mere coincidences. Your statement is misleading. No one is using btrfs on servers. Debian and Ubuntu use ext4 by default. RHEL removed support for btrfs long ago, and it's not coming back: > Red Hat will not be moving Btrfs to a fully supported feature. It was fully removed in Red Hat Enterprise Linux 8.

bagxrvxpepzn 1y ago

Bcachefs comes off as a vanity project, as most open source software seems to be. The public rationale for it also strongly projects NIH. Therefore, its demise as everyone comes to grips with that is not very surprising. Hopefully this development serves to inoculate the kernel community against future wastes of resources. Perhaps the vetting process will become more rigorous before big merges like this.

charcircuit 1y ago

It's sad that it came with this, but in the end Linus and Kent had different ideas on how distribution of fixes should work so it makes sense that we have reached a situation where Kent controls the distribution frequency of the file system.

lesser-shadow 1y ago

[dead]

theLegionWithin 1y ago

good riddance

ErichLoew 1y ago

I use BTRFS, ZFS and BCACHEFS --> Recompiling ZFS for LATEST kernels is sometimes tricky. --> BTRFS and BCACHEFS are integral components of the kernel, hence their usage in combination with recompiling LATEST kernels is really a charm. And now ... BCACHEFS (like ZFS) is as well externalized, likely. --> I'm just shocked. --> And I still hope that all goes Best and BCACHEFS keeps staying in kernel.