18 ms·

Bcachefs Goes to "Externally Maintained"

227 points by ksec 1y ago

Volundr 1y ago
Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date.
- WD-42 1y ago
  The article says that bcachefs is not being removed from the mainline kernel. This looks like mostly a workaround for Linus and other kernel devs to not have to deal with Kent directly.
  - ffsm8 1y ago
    The three listed options in the OP thread were * Another kernel Dev takes over management and they tread it as a fork (highly unlikely according to their estimate) * Kent hires someone to upstream the changes for him and Kent stops complaining wrt when it's getting merged * Bcachefs gets no maintenance and will likely be removed in the next major release I do not know him personally, but most interactions I've read online by him sounded grounded and not particularly offensive, so I'm abstaining from making any kind of judgement on it. But while I have no stake in this, Drama really does seem to follow Kent around for one reason or another. And it's never his fault if you take him by his public statements - which I want to repeat: he sounds very grounded and not offensive to me whatsoever.
    - sarlalian 1y ago
      If you look at all the places where Kent has had drama, the common element is him and environments that have pretty rigid workflows. The common thread seems to be him not respecting workflows and processes that those places have, that inconvenience his goals. So, he ignores the workflows and processes of those places, and creates a constant state of friction and papercuts for those who he needs to accomplish his goals. They eventually get fed up, and either say no, not working with you anymore, or no, you’re not welcome to contribute here anymore. He’s not super offensive, but he will tell a Debian package maintainer that their process sucks, and the should change it and they are being stupid by following that process. Overall, he seems a bit entitled, and unwilling to compromise with others. It’s not just Kent though, the areas that seem to be the most problematic for him, are when it’s an unstoppable force (Kent), and an immovable wall (Linux / Debian). Working in the Linux kernel is well known for its frustrations and the personal conflict that it creates, to the point that there are almost no linux kernel devs/maintainers that aren’t paid to do the work. You can see a similar set of events happen with Rust4Linux people, Asahi linux project and their R4L drivers, etc.
    - BoredPositron 1y ago
      Grounded? Not offensive? https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrtrXsXiLrn+qXTx4-Sy6MA@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrt... https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...
      - ffsm8 1y ago
        The first one is by Linus? And his replies (at least the ones I read) are - to me- less aggressive then the rest of the mails in that chain The second has one offensive remark: > Get your head examined. And get the fuck out of here with this shit. which I thought he admitted was out of line and - said sorry for. Or do I misremember? I admit once again, I'm still completely uninvolved and merely saw it play out on the internet.
        yencabulator 1y ago
        If you read his replies downthread from that, Kent seems to be going through a lot of effort to not apologize, in any form, and prefers talking about how other people were mean to him. I had high hopes for bcachefs. sigh
  - tux3 1y ago
    It's complicated, no one really knows what "externally maintained" entails at the moment. Linus is not exactly poised to pull directly from Kent, and there is no solution lined-up at the moment. Both Linus and Kent drive a hard bargain, and it's not as simple as finding someone else to blindly forward bcachefs patches. At the first sign of conflict, the poor person in the middle would have no power, no way to make anyone back down, and we'd be back to square one. It's in limbo, and there is still time, but if left to bitrot it will be removed eventually.
    - immibis 1y ago
      That person would be accountable to Linus, but not to Kent.
      - tux3 1y ago
        Unfortunately, there's also nothing they can do if Kent says no. Say there's a disagreement on a patch that touches something outside fs/bcachefs, that person can't exactly write their own patches incorporating the feedback. They're not going to fork and maintain their own patches. They'd be stuck between a rock and a hard place, and that gets us back to a deadlock. The issue is that I have never seen Kent back down a single time. Kent will explain in details why the rules are bullshit and don't apply in this particular case, every single time, without any room for compromise. If the only problem was when to send patches, that would be one thing. But disagreements over patches aren't just a timing problem that can be routed around.
        koverstreet 1y ago
        The key thing here is I've never challenged Linus's authority on patches outside fs/bcachefs/; I've quietly respun pull requests for that, on more than one occasion. The point of contention here was a patch within fs/bcachefs/, which was repair code to make sure users didn't lose data. If we can't have clear boundaries and delineations of responsibility, there really is no future for bcachefs in the kernel; my core mission is a rock solid commitment to reliability and robustness, including being responsive to issues users hit, and we've seen repeatedly that the kernel process does not share those priorities.
- deleted 1y ago
  [deleted]
- mustache_kimono 1y ago
  > Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date. Your distro could very easily include bcachefs if it wishes? Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, that very particular problem doesn't exist re: bcachefs? The problem with bcachefs is the problem with btrfs. It mostly still doesn't work to solve the problems ZFS already solves.
  - kstrauser 1y ago
    > Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild I can think of non-religious reasons to want to avoid legal fights with Oracle.
    - mustache_kimono 1y ago
      >> I can think of non-religious reasons to want to avoid legal fights with Oracle. Oh, certainly, but that's really not the problem posed right now. Oracle's own lawyers have said they see no problem with the combination, and Ubuntu has shipped the Linux + ZFS combination for years without a lawsuit.[0][1] In the 1990s, Microsoft/SCO, like you, would also fear monger about open source and lawsuits, and we in the OSS community mostly called this "FUD" (fear, uncertainty, and doubt). Whereas now, almost 10 years into this experiment, we know more about the ZFS + Linux combination, and what Oracle will do about it, than most other open questions in OSS, and the answer is that some in OSS community have chosen to instead participate in the same kind of FUD because of a very online, very uninformed internecine licensing debate. [0]: https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s [1]: https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubuntu-16-04 https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubun...
  - jchw 1y ago
    > Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, I think the Linux Kernel just doesn't want to be potentially in violation of Oracle's copyrights. That really doesn't seem that unreasonable to me, even if it feels pointless to you.
- NewJazz 1y ago
  FWIW DKMS is not the only way to distribute out of tree modules. https://github.com/chimera-linux/ckms https://github.com/chimera-linux/ckms
sabedevops 1y ago
[flagged]
- pdmccormick 1y ago
  Could you be more specific about where you think the brain rot is? I thought the issues regarding bcachefs and Linux kernel development revolved around respecting conventions for code freezes and release candidates. It seemed more about getting along socially than technical objections to the technology.
- vorgol 1y ago
  "Get your head examined. And get the fuck out of here with this shit." -- Kent Overstreet, bcachefs maintainer: https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...
  - cozzyd 1y ago
    Sadly my nonacore phone's soul is too heavy (or light)? to visit that site.
    - opan 1y ago
      Worked on my OnePlus 8T running LineageOS with no gapps and using Fennec F-Droid for the browser. Could you have a useragent or extension[1] it didn't like? I know that on my PC, GNOME's Gitlab specifically required me to change my UA to get it to load while every other Anubis config I've come across has been fine. I do notice LKML's is using difficulty 4, though, which I think is higher than I usually see. [1] Due to an unrelated bug in latest Fennec, I currently have all my extensions disabled or else all pages stop loading at all. Normally use uBlock Origin, Tampermonkey, etc.
      - cozzyd 1y ago
        The problem is presumably this: https://anubis.techaro.lol/blog/2025/cpu-core-odd/ https://anubis.techaro.lol/blog/2025/cpu-core-odd/
deleted 1y ago
[deleted]
rstat1 1y ago
Surprised it took this long.
LeoPanthera 1y ago
It's orphaned in Debian as well, but I'm not sure what significant advantages it has over btrfs, which is very stable these days.
- betaby 1y ago
  btrfs was unusable in multi disk setup for kernels 6.1 and older. Didn't try since then. How's stable btrs today in such setups? Also see https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta
  - LeoPanthera 1y ago
    It's sort of frustrating that this constantly comes up. It's true that btrfs does have issues with RAID-5 and RAID-6 configurations, but this is frequently used (not necessarily by you) as some kind of gotcha as to why you shouldn't use it at all. That's insane. I promise that disk spanning issues won't affect your use of it on your tiny ThinkPad SSD. It's important to note that striping and mirroring works just fine. It's only the 5/6 modes that are unstable: https://btrfs.readthedocs.io/en/stable/Status.html#block-group-profiles https://btrfs.readthedocs.io/en/stable/Status.html#block-gro...
    - rendaw 1y ago
      > on your tiny ThinkPad SSD Ad hominem. My thinkpad ssd is massive.
      - LeoPanthera 1y ago
        Good news, it will work just fine on that too.
    - AaronFriel 1y ago
      Respectfully to the maintainers: How can this be a stable filesystem if parity is unstable and risks data loss? How has this been allowed to happen? It just seems so profoundly unserious to me.
omoikane 1y ago
Related: Linux CoC Announces Decision Wrt Kent Overstreet (Bcachefs) (kernel.org) https://news.ycombinator.com/item?id=42221564 https://news.ycombinator.com/item?id=42221564 - 2024-11-23, 103 comments
- wging 1y ago
  There's been much more recent friction between various parties, so I don't think this most recent news is a direct result of that decision. See for instance https://news.ycombinator.com/item?id=44464396 https://news.ycombinator.com/item?id=44464396
sevg 1y ago
Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).
- toast0 1y ago
  It's not just kernel development. In the lwn thread, he mentioned and then demonstrated difficulty working with Debian developers as well. IMHO, what his communications show is an unwillingness to acknowledge that other projects that include his work have focus, priorities, and policies that are not the same as that of his project. Also, expecting exceptions to be made for his case, since exceptions have been made in other cases. Again IMHO, I think he would be better off developing apart with an announcement mailing list. When urgent changes are made, send to the announcement list. Let other interested parties sort out the process of getting those changes into the kernel and distributions. If people come with bug reports from old versions distributed by others, let them know how to get the most up to date version from his repository, and maybe gently poke the distributors. Yes, that means users will have older versions and not get fixes immediately. But what he's doing isn't working to get fixes to users immediately either.
- ajb 1y ago
  I think Kent is in the wrong here, but it really doesn't help that the kernel people from Linus on down are seemingly unable to explain the problem, and instead resort to playground insults. Apart from being unprofessional and making for a hostile work environment, it doesn't really communicate why Kent's actions are problematic, so I've some sympathy for his not believing that they are.
  - sevg 1y ago
    > it doesn't really communicate why Kent's actions are problematic I agree that the kernel community can be a hostile environment. Though I’d argue that people _have_ tried to explain things to Kent, multiple times. At least a few have been calm, respectful attempts. Sadly, Kent responds to everything in an email except the key part that is being pointed out to him (usually his behavior). Or deflects by going on the attack. And generally refuses to apologise.
betaby 1y ago
The sad part, that despite the years of the development BTRS never reached the parity with ZFS. And yesterday's news "Josef Bacik who is a long-time Btrfs developer and active co-maintainer alongside David Sterba is leaving Meta. Additionally, he's also stepping back from Linux kernel development as his primary job." see https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta There is no 'modern' ZFS-like fs in Linux nowadays.
- ibgeek 1y ago
  This isn’t BTRFS
  - NewJazz 1y ago
    Btrfs is the closest in-tree bcachefs alternative.
  - doubletwoyou 1y ago
    This might not be directly about btrfs but bcachefs zfs and btrfs are the only filesystems for Linux that provide modern features like transparent compression, snapshots, and CoW. zfs is out of tree leaving it as an unviable option for many people. This news means that bcachefs is going to be in a very weird state in-kernel, which leaves only btrfs as the only other in-tree ‘modern’ filesystem. This news about bcachefs has ramifications about the state of ‘modern’ FSes in Linux, and I’d say this news about the btrfs maintainer taking a step back is related to this.
    - ajross 1y ago
      Meh. This war was stale like nine years ago. At this point the originally-beaten horse has decomposed into soil. My general reply to this is: 1. The dm layer gives you cow/snapshots for any filesystem you want already and has for more than a decade. Some implementations actually use it for clever trickery like updates, even. Anyone who has software requirements in this space (as distinct from "wants to yell on the internet about it") is very well served. 2. Compression seems silly in the modern world. Virtually everything is already compressed. To first approximation, every byte in persistent storage anywhere in the world is in a lossy media format. And the ones that aren't are in some other cooked format. The only workloads where you see significant use of losslessly-compressible data are in situations (databases) where you have app-managed storage performance (and who see little value from filesystem choice) or ones (software building, data science, ML training) where there's lots of ephemeral intermediate files being produced. And again those are usages where fancy filesystems are poorly deployed, you're going to throw it all away within hours to days anyway. Filesystems are a solved problem. If ZFS disappeared from the world today... really who would even care? Only those of us still around trying to shout on the internet.
NewJazz 1y ago
FreeBSD is giving me a sultry look as I ponder my NAS build.
- kstrauser 1y ago
  I'm in that boat. I'm looking over at that Synology unit sitting in the corner of my living room, knowing it'll be the last of its kind to live here, and wondering what its replacement will look like. FreeBSD's been good to me and it might be time to reintroduce myself to it.
  - nichos 1y ago
    Doesn't TrueNAS (Linux version) come with ZFS?
    - magicalhippo 1y ago
      TrueNAS Scale, which is the Linux variant, does indeed come with ZFS. The comapny behind it, iXsystems, pays for ZFS developers as well.
- _0xdd 1y ago
  Go for it. I made the switch ~10 years ago and didn't regret it at all. First-class, rock solid ZFS integration. Saved my data on more than one occasion.
- bpye 1y ago
  There are some Linux distros with ZFS as a near first class citizen. NixOS is one, I believe Alpine is another.
  - mrighele 1y ago
    Ubuntu too.
  - bombcar 1y ago
    I looked long and hard at FreeBSD and eventually went with Gentoo on ZFS, as I was familiar with Gentoo and ZFS wasn't hard to add.
tarruda 1y ago
Since the existing bcachefs driver will not be removed, and the problem is the bcachefs developer not following the rules, I wonder if someone else could take on the role of pulling bcachefs changes into the mainline, while also following the merge window rules.
- koverstreet 1y ago
  No, the problem wasn't following the rules. The patch that kicked off the current conflict was the 'journal_rewind' patch; we recently (6.15) had the worst bug in the entire history upstream - it was taking out entire subvolumes. The third report got me a metadata dump with everything I needed to debug the issue, thank god, and now we have a great deal of hardening to ensure a bug like this can never happen again. Subsequently, I wrote new repair code, which fully restored the filesystem of the 3rd user hit by the bug (first two had backups). Linus then flipped out because it was listed as a 'feature' in the pull request; it was only listed that way to make sure that users would know about it if they were affected by the original bug and needed it. Failure to maintain your data is always a bug for a filesystem, and repair code is a bugfix. In the private maintainer thread, and even in public, things went completely off the rails, with Linus and Ted basically asserting that they knew better than I do which bcachefs patches are regression risks (seriously), and a page and a half rant from Linus on how he doesn't trust my judgement, and a whole lot more. There have been many repeated arguments like this over bugfixes. The thing is, since then I started perusing pull requests from other subsystems, and it looks like I've actually been more conservative with what I consider a critical bugfix (and send outside the merge window) than other subsystems. The _only_ thing that's been out of the ordinary with bcachefs has been the volume of bugfixes - but that's exactly what you'd expect to see from a new filesystem that's stabilizing rapidly and closing out user bug reports - high volume of pure bugfixing is exactly what you want to see. So given that, I don't think having a go-between would solve anything.
  - nirava 1y ago
    To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he has for the last however many decades. Repair code is a feature if Linus says it is a feature. 2. Being correct comes second to being agreeable in human-human interactions. For example, dunking on x file system does not work as a defense when the person opposite you is a x file system maintainer. 3. rules are rules, and generally don't have to be "correct" to be enforced in an organization I think your perceived "unfairness" might make sense if you just thought of these things as un-workaroundable constraints, Just like the fact that SSDs wear out over time.
uecker 1y ago
Who would use a file system which essentially seems to be developed by a single person? A bus-factor of one seems unacceptable for a FS. But maybe I am wrong and there are other developers, then why do they not take over upstreaming if the main developer is unable to collaborate with the kernel community.
- wmf 1y ago
  It's that good.
- commandersaki 1y ago
  I did for my laptop and Raspberry Pi which I didn't care much about. It was great being able to interact with Kent over IRC to sort out problems and when he is actually available he's really helpeful, but it made me realise that bcachefs has a long ways to go, and I have come to the realisation bus factor 1 is not something I'd want long term.
- kalleboo 1y ago
  Exactly, some of us remember thinking using reiserfs was a great idea...
shmerl 1y ago
Some collaboration failing there, no technical reasons for it. I hope they'll sort this nonsense out and it will go back to normal upstream maintenance.
- masklinn 1y ago
  It won’t. Kent is in this very post (as well as TFA) showing that he’s not learned anything
  - rob_c 1y ago
    Shame, at the very least I was hoping this would lead to approaching someone to work as a go between. (I find it difficult to believe nobody tried to step up to that position either)
    - shmerl 1y ago
      Yeah, I don't really get why Kent wouldn't find people to handle upstreaming process that will satisfy Linus if he can't handle it himself. It would solve the problem and avoid all this collaboration friction. If there is a need for out of tree emergency patches (until they get merged), it can always be communicated somewhere.
qalmakka 1y ago
The whole situation is moronic at best. Linux needs a decent modern filesystem in tree. ZFS would easily be it, but unfortunately Sun decided back in the '00s to fuck Linux because they wanted to push Solaris instead. Little they knew ZFS ended up being FreeBSD top feature for years. Btrfs is constantly eating people data, it's a bad joke nowadays. Right now on Linux you're basically forced to constantly deal with out of tree ZFS or accept that thinly provisioned XFS over LVM2 will inevitably cause you to lose data.
- goneri 1y ago
  Btrfs is NOT constantly eating people data. You have nothing to back this statement. It's widely used and the default filesystem of several distributions. Most of the problems are like for the other filesystem: caused by the hardware. I've been using it for more than 10 years without any problem and enjoy the experience. And like for any filesystem, I backup my data frequently (with btrbk, thanks for asking).
  - AaronFriel 1y ago
    btrfs has eaten my data, which was probably my bad for trying out a newly stable filesystem around 15 years ago. there are plenty of bug reports of btrfs eating other people's data in the years since. It's probably mostly stable now, but it's silly to act like it's a paragon of stability in the kernel.
    - wtallis 1y ago
      > but it's silly to act like it's a paragon of stability in the kernel. And it's dishonest to act like bugs from 15 years ago justify present-tense claims that it is constantly eating people's data and is a bad joke. Nobody's arguing that btrfs doesn't have a past history of data loss, more than a decade ago; that's not what's being questioned here.
      - AaronFriel 1y ago
        There's no need to call someone pointing out instability of a filesystem dishonest. That's bad faith. I don't get why folks feel the need to come out and cheer for a tool like this, do you have skin in the game on whether or not btrfs is considered stable? Are you a contributor? I don't get it. But since you asked - let me find some recent bugs. 5.15.37 - fixes data corruption in database reads using btrfs https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.37 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.... 5.15.65 - fixes double allocation and cache corruption https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.65 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.... 6.1.105 - fixes O_APPEND with direct i/o can write corurpted files https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.105 https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... 6.1.110 - fixes fsync race and corruption https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.110 https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... 6.2.16 - fixes truncation of files causing data corruption https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.16 https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.1... btrfs-progs 6.2 fixes corruption on zstd extent read https://btrfs.readthedocs.io/en/latest/CHANGES.html https://btrfs.readthedocs.io/en/latest/CHANGES.html 6.15.3, 4: possible data corruption, seems to be reparable: https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix Are people that encountered these also dishonest?
gdgghhhhh 1y ago
It's amazing how many of the "experts" here don't get that bcachefs != btrfs
- arccy 1y ago
  people understand they're different, but if bcachefs is out, then that leaves btrfs as the only modern in-tree filesystem, but apparently you can't trust it with important data either.
  - zitsarethecure 1y ago
    I've been using btrfs on my NAS for years and have not had any problems. I suspect there are a hell of a lot of people like me you will not hear about because people don't generally get as vocal when things just work.
    - aaronmdjones 1y ago
      The venn diagram of "people who want a modern copy-on-write filesystem with snapshots to manage large quantities of data" and "people who want a massive pool of fault-tolerant storage" (e.g. building a NAS) has some pretty significant overlap. The latter is where BTRFS is still hobbled: While the RAID-0, RAID-1, & RAID-10 modes work absolutely fine, the RAID-5 & RAID-6 modes are still broken, with an explicit warning during mkfs time (and in the manpages) that the feature is still experimental and should not be used to hold data that you care about retaining. This has, and continues to, bite people, with terabytes of data loss (backups are important, people!). That then sours them on every other aspect of ever using BTRFS again.
      - procaryote 1y ago
        If you ignore explicit warnings at mkfs time and then get upset the warning was accurate, you can't really fully blame the file system for it. Just raid on a lower layer and btrfs on top.
        1y ago
classified 1y ago
[flagged]

227 points by ksec 1y ago

Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date.

WD-42 1y ago
The article says that bcachefs is not being removed from the mainline kernel. This looks like mostly a workaround for Linus and other kernel devs to not have to deal with Kent directly.
- ffsm8 1y ago
  The three listed options in the OP thread were * Another kernel Dev takes over management and they tread it as a fork (highly unlikely according to their estimate) * Kent hires someone to upstream the changes for him and Kent stops complaining wrt when it's getting merged * Bcachefs gets no maintenance and will likely be removed in the next major release I do not know him personally, but most interactions I've read online by him sounded grounded and not particularly offensive, so I'm abstaining from making any kind of judgement on it. But while I have no stake in this, Drama really does seem to follow Kent around for one reason or another. And it's never his fault if you take him by his public statements - which I want to repeat: he sounds very grounded and not offensive to me whatsoever.
  - sarlalian 1y ago
    If you look at all the places where Kent has had drama, the common element is him and environments that have pretty rigid workflows. The common thread seems to be him not respecting workflows and processes that those places have, that inconvenience his goals. So, he ignores the workflows and processes of those places, and creates a constant state of friction and papercuts for those who he needs to accomplish his goals. They eventually get fed up, and either say no, not working with you anymore, or no, you’re not welcome to contribute here anymore. He’s not super offensive, but he will tell a Debian package maintainer that their process sucks, and the should change it and they are being stupid by following that process. Overall, he seems a bit entitled, and unwilling to compromise with others. It’s not just Kent though, the areas that seem to be the most problematic for him, are when it’s an unstoppable force (Kent), and an immovable wall (Linux / Debian). Working in the Linux kernel is well known for its frustrations and the personal conflict that it creates, to the point that there are almost no linux kernel devs/maintainers that aren’t paid to do the work. You can see a similar set of events happen with Rust4Linux people, Asahi linux project and their R4L drivers, etc.
  - BoredPositron 1y ago
    Grounded? Not offensive? https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrtrXsXiLrn+qXTx4-Sy6MA@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrt... https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...
    - ffsm8 1y ago
      The first one is by Linus? And his replies (at least the ones I read) are - to me- less aggressive then the rest of the mails in that chain The second has one offensive remark: > Get your head examined. And get the fuck out of here with this shit. which I thought he admitted was out of line and - said sorry for. Or do I misremember? I admit once again, I'm still completely uninvolved and merely saw it play out on the internet.
      - yencabulator 1y ago
        If you read his replies downthread from that, Kent seems to be going through a lot of effort to not apologize, in any form, and prefers talking about how other people were mean to him. I had high hopes for bcachefs. sigh
- tux3 1y ago
  It's complicated, no one really knows what "externally maintained" entails at the moment. Linus is not exactly poised to pull directly from Kent, and there is no solution lined-up at the moment. Both Linus and Kent drive a hard bargain, and it's not as simple as finding someone else to blindly forward bcachefs patches. At the first sign of conflict, the poor person in the middle would have no power, no way to make anyone back down, and we'd be back to square one. It's in limbo, and there is still time, but if left to bitrot it will be removed eventually.
  - immibis 1y ago
    That person would be accountable to Linus, but not to Kent.
    - tux3 1y ago
      Unfortunately, there's also nothing they can do if Kent says no. Say there's a disagreement on a patch that touches something outside fs/bcachefs, that person can't exactly write their own patches incorporating the feedback. They're not going to fork and maintain their own patches. They'd be stuck between a rock and a hard place, and that gets us back to a deadlock. The issue is that I have never seen Kent back down a single time. Kent will explain in details why the rules are bullshit and don't apply in this particular case, every single time, without any room for compromise. If the only problem was when to send patches, that would be one thing. But disagreements over patches aren't just a timing problem that can be routed around.
      - koverstreet 1y ago
        The key thing here is I've never challenged Linus's authority on patches outside fs/bcachefs/; I've quietly respun pull requests for that, on more than one occasion. The point of contention here was a patch within fs/bcachefs/, which was repair code to make sure users didn't lose data. If we can't have clear boundaries and delineations of responsibility, there really is no future for bcachefs in the kernel; my core mission is a rock solid commitment to reliability and robustness, including being responsive to issues users hit, and we've seen repeatedly that the kernel process does not share those priorities.
deleted 1y ago
[deleted]
mustache_kimono 1y ago
> Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date. Your distro could very easily include bcachefs if it wishes? Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, that very particular problem doesn't exist re: bcachefs? The problem with bcachefs is the problem with btrfs. It mostly still doesn't work to solve the problems ZFS already solves.
- kstrauser 1y ago
  > Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild I can think of non-religious reasons to want to avoid legal fights with Oracle.
  - mustache_kimono 1y ago
    >> I can think of non-religious reasons to want to avoid legal fights with Oracle. Oh, certainly, but that's really not the problem posed right now. Oracle's own lawyers have said they see no problem with the combination, and Ubuntu has shipped the Linux + ZFS combination for years without a lawsuit.[0][1] In the 1990s, Microsoft/SCO, like you, would also fear monger about open source and lawsuits, and we in the OSS community mostly called this "FUD" (fear, uncertainty, and doubt). Whereas now, almost 10 years into this experiment, we know more about the ZFS + Linux combination, and what Oracle will do about it, than most other open questions in OSS, and the answer is that some in OSS community have chosen to instead participate in the same kind of FUD because of a very online, very uninformed internecine licensing debate. [0]: https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s [1]: https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubuntu-16-04 https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubun...
- jchw 1y ago
  > Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, I think the Linux Kernel just doesn't want to be potentially in violation of Oracle's copyrights. That really doesn't seem that unreasonable to me, even if it feels pointless to you.
NewJazz 1y ago
FWIW DKMS is not the only way to distribute out of tree modules. https://github.com/chimera-linux/ckms https://github.com/chimera-linux/ckms

sabedevops 1y ago

[flagged]

pdmccormick 1y ago
Could you be more specific about where you think the brain rot is? I thought the issues regarding bcachefs and Linux kernel development revolved around respecting conventions for code freezes and release candidates. It seemed more about getting along socially than technical objections to the technology.
vorgol 1y ago
"Get your head examined. And get the fuck out of here with this shit." -- Kent Overstreet, bcachefs maintainer: https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...
- cozzyd 1y ago
  Sadly my nonacore phone's soul is too heavy (or light)? to visit that site.
  - opan 1y ago
    Worked on my OnePlus 8T running LineageOS with no gapps and using Fennec F-Droid for the browser. Could you have a useragent or extension[1] it didn't like? I know that on my PC, GNOME's Gitlab specifically required me to change my UA to get it to load while every other Anubis config I've come across has been fine. I do notice LKML's is using difficulty 4, though, which I think is higher than I usually see. [1] Due to an unrelated bug in latest Fennec, I currently have all my extensions disabled or else all pages stop loading at all. Normally use uBlock Origin, Tampermonkey, etc.
    - cozzyd 1y ago
      The problem is presumably this: https://anubis.techaro.lol/blog/2025/cpu-core-odd/ https://anubis.techaro.lol/blog/2025/cpu-core-odd/

deleted 1y ago

[deleted]

rstat1 1y ago

Surprised it took this long.

LeoPanthera 1y ago

It's orphaned in Debian as well, but I'm not sure what significant advantages it has over btrfs, which is very stable these days.

betaby 1y ago
btrfs was unusable in multi disk setup for kernels 6.1 and older. Didn't try since then. How's stable btrs today in such setups? Also see https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta
- LeoPanthera 1y ago
  It's sort of frustrating that this constantly comes up. It's true that btrfs does have issues with RAID-5 and RAID-6 configurations, but this is frequently used (not necessarily by you) as some kind of gotcha as to why you shouldn't use it at all. That's insane. I promise that disk spanning issues won't affect your use of it on your tiny ThinkPad SSD. It's important to note that striping and mirroring works just fine. It's only the 5/6 modes that are unstable: https://btrfs.readthedocs.io/en/stable/Status.html#block-group-profiles https://btrfs.readthedocs.io/en/stable/Status.html#block-gro...
  - rendaw 1y ago
    > on your tiny ThinkPad SSD Ad hominem. My thinkpad ssd is massive.
    - LeoPanthera 1y ago
      Good news, it will work just fine on that too.
  - AaronFriel 1y ago
    Respectfully to the maintainers: How can this be a stable filesystem if parity is unstable and risks data loss? How has this been allowed to happen? It just seems so profoundly unserious to me.

omoikane 1y ago

Related: Linux CoC Announces Decision Wrt Kent Overstreet (Bcachefs) (kernel.org) https://news.ycombinator.com/item?id=42221564 https://news.ycombinator.com/item?id=42221564 - 2024-11-23, 103 comments

wging 1y ago
There's been much more recent friction between various parties, so I don't think this most recent news is a direct result of that decision. See for instance https://news.ycombinator.com/item?id=44464396 https://news.ycombinator.com/item?id=44464396

sevg 1y ago

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

toast0 1y ago
It's not just kernel development. In the lwn thread, he mentioned and then demonstrated difficulty working with Debian developers as well. IMHO, what his communications show is an unwillingness to acknowledge that other projects that include his work have focus, priorities, and policies that are not the same as that of his project. Also, expecting exceptions to be made for his case, since exceptions have been made in other cases. Again IMHO, I think he would be better off developing apart with an announcement mailing list. When urgent changes are made, send to the announcement list. Let other interested parties sort out the process of getting those changes into the kernel and distributions. If people come with bug reports from old versions distributed by others, let them know how to get the most up to date version from his repository, and maybe gently poke the distributors. Yes, that means users will have older versions and not get fixes immediately. But what he's doing isn't working to get fixes to users immediately either.
ajb 1y ago
I think Kent is in the wrong here, but it really doesn't help that the kernel people from Linus on down are seemingly unable to explain the problem, and instead resort to playground insults. Apart from being unprofessional and making for a hostile work environment, it doesn't really communicate why Kent's actions are problematic, so I've some sympathy for his not believing that they are.
- sevg 1y ago
  > it doesn't really communicate why Kent's actions are problematic I agree that the kernel community can be a hostile environment. Though I’d argue that people _have_ tried to explain things to Kent, multiple times. At least a few have been calm, respectful attempts. Sadly, Kent responds to everything in an email except the key part that is being pointed out to him (usually his behavior). Or deflects by going on the attack. And generally refuses to apologise.

betaby 1y ago

The sad part, that despite the years of the development BTRS never reached the parity with ZFS. And yesterday's news "Josef Bacik who is a long-time Btrfs developer and active co-maintainer alongside David Sterba is leaving Meta. Additionally, he's also stepping back from Linux kernel development as his primary job." see https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta There is no 'modern' ZFS-like fs in Linux nowadays.

ibgeek 1y ago
This isn’t BTRFS
- NewJazz 1y ago
  Btrfs is the closest in-tree bcachefs alternative.
- doubletwoyou 1y ago
  This might not be directly about btrfs but bcachefs zfs and btrfs are the only filesystems for Linux that provide modern features like transparent compression, snapshots, and CoW. zfs is out of tree leaving it as an unviable option for many people. This news means that bcachefs is going to be in a very weird state in-kernel, which leaves only btrfs as the only other in-tree ‘modern’ filesystem. This news about bcachefs has ramifications about the state of ‘modern’ FSes in Linux, and I’d say this news about the btrfs maintainer taking a step back is related to this.
  - ajross 1y ago
    Meh. This war was stale like nine years ago. At this point the originally-beaten horse has decomposed into soil. My general reply to this is: 1. The dm layer gives you cow/snapshots for any filesystem you want already and has for more than a decade. Some implementations actually use it for clever trickery like updates, even. Anyone who has software requirements in this space (as distinct from "wants to yell on the internet about it") is very well served. 2. Compression seems silly in the modern world. Virtually everything is already compressed. To first approximation, every byte in persistent storage anywhere in the world is in a lossy media format. And the ones that aren't are in some other cooked format. The only workloads where you see significant use of losslessly-compressible data are in situations (databases) where you have app-managed storage performance (and who see little value from filesystem choice) or ones (software building, data science, ML training) where there's lots of ephemeral intermediate files being produced. And again those are usages where fancy filesystems are poorly deployed, you're going to throw it all away within hours to days anyway. Filesystems are a solved problem. If ZFS disappeared from the world today... really who would even care? Only those of us still around trying to shout on the internet.

NewJazz 1y ago

FreeBSD is giving me a sultry look as I ponder my NAS build.

kstrauser 1y ago
I'm in that boat. I'm looking over at that Synology unit sitting in the corner of my living room, knowing it'll be the last of its kind to live here, and wondering what its replacement will look like. FreeBSD's been good to me and it might be time to reintroduce myself to it.
- nichos 1y ago
  Doesn't TrueNAS (Linux version) come with ZFS?
  - magicalhippo 1y ago
    TrueNAS Scale, which is the Linux variant, does indeed come with ZFS. The comapny behind it, iXsystems, pays for ZFS developers as well.
_0xdd 1y ago
Go for it. I made the switch ~10 years ago and didn't regret it at all. First-class, rock solid ZFS integration. Saved my data on more than one occasion.
bpye 1y ago
There are some Linux distros with ZFS as a near first class citizen. NixOS is one, I believe Alpine is another.
- mrighele 1y ago
  Ubuntu too.
- bombcar 1y ago
  I looked long and hard at FreeBSD and eventually went with Gentoo on ZFS, as I was familiar with Gentoo and ZFS wasn't hard to add.

tarruda 1y ago

Since the existing bcachefs driver will not be removed, and the problem is the bcachefs developer not following the rules, I wonder if someone else could take on the role of pulling bcachefs changes into the mainline, while also following the merge window rules.

koverstreet 1y ago
No, the problem wasn't following the rules. The patch that kicked off the current conflict was the 'journal_rewind' patch; we recently (6.15) had the worst bug in the entire history upstream - it was taking out entire subvolumes. The third report got me a metadata dump with everything I needed to debug the issue, thank god, and now we have a great deal of hardening to ensure a bug like this can never happen again. Subsequently, I wrote new repair code, which fully restored the filesystem of the 3rd user hit by the bug (first two had backups). Linus then flipped out because it was listed as a 'feature' in the pull request; it was only listed that way to make sure that users would know about it if they were affected by the original bug and needed it. Failure to maintain your data is always a bug for a filesystem, and repair code is a bugfix. In the private maintainer thread, and even in public, things went completely off the rails, with Linus and Ted basically asserting that they knew better than I do which bcachefs patches are regression risks (seriously), and a page and a half rant from Linus on how he doesn't trust my judgement, and a whole lot more. There have been many repeated arguments like this over bugfixes. The thing is, since then I started perusing pull requests from other subsystems, and it looks like I've actually been more conservative with what I consider a critical bugfix (and send outside the merge window) than other subsystems. The _only_ thing that's been out of the ordinary with bcachefs has been the volume of bugfixes - but that's exactly what you'd expect to see from a new filesystem that's stabilizing rapidly and closing out user bug reports - high volume of pure bugfixing is exactly what you want to see. So given that, I don't think having a go-between would solve anything.
- nirava 1y ago
  To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he has for the last however many decades. Repair code is a feature if Linus says it is a feature. 2. Being correct comes second to being agreeable in human-human interactions. For example, dunking on x file system does not work as a defense when the person opposite you is a x file system maintainer. 3. rules are rules, and generally don't have to be "correct" to be enforced in an organization I think your perceived "unfairness" might make sense if you just thought of these things as un-workaroundable constraints, Just like the fact that SSDs wear out over time.

uecker 1y ago

Who would use a file system which essentially seems to be developed by a single person? A bus-factor of one seems unacceptable for a FS. But maybe I am wrong and there are other developers, then why do they not take over upstreaming if the main developer is unable to collaborate with the kernel community.

wmf 1y ago
It's that good.
commandersaki 1y ago
I did for my laptop and Raspberry Pi which I didn't care much about. It was great being able to interact with Kent over IRC to sort out problems and when he is actually available he's really helpeful, but it made me realise that bcachefs has a long ways to go, and I have come to the realisation bus factor 1 is not something I'd want long term.
kalleboo 1y ago
Exactly, some of us remember thinking using reiserfs was a great idea...

shmerl 1y ago

Some collaboration failing there, no technical reasons for it. I hope they'll sort this nonsense out and it will go back to normal upstream maintenance.

masklinn 1y ago
It won’t. Kent is in this very post (as well as TFA) showing that he’s not learned anything
- rob_c 1y ago
  Shame, at the very least I was hoping this would lead to approaching someone to work as a go between. (I find it difficult to believe nobody tried to step up to that position either)
  - shmerl 1y ago
    Yeah, I don't really get why Kent wouldn't find people to handle upstreaming process that will satisfy Linus if he can't handle it himself. It would solve the problem and avoid all this collaboration friction. If there is a need for out of tree emergency patches (until they get merged), it can always be communicated somewhere.

qalmakka 1y ago

The whole situation is moronic at best. Linux needs a decent modern filesystem in tree. ZFS would easily be it, but unfortunately Sun decided back in the '00s to fuck Linux because they wanted to push Solaris instead. Little they knew ZFS ended up being FreeBSD top feature for years. Btrfs is constantly eating people data, it's a bad joke nowadays. Right now on Linux you're basically forced to constantly deal with out of tree ZFS or accept that thinly provisioned XFS over LVM2 will inevitably cause you to lose data.

goneri 1y ago
Btrfs is NOT constantly eating people data. You have nothing to back this statement. It's widely used and the default filesystem of several distributions. Most of the problems are like for the other filesystem: caused by the hardware. I've been using it for more than 10 years without any problem and enjoy the experience. And like for any filesystem, I backup my data frequently (with btrbk, thanks for asking).
- AaronFriel 1y ago
  btrfs has eaten my data, which was probably my bad for trying out a newly stable filesystem around 15 years ago. there are plenty of bug reports of btrfs eating other people's data in the years since. It's probably mostly stable now, but it's silly to act like it's a paragon of stability in the kernel.
  - wtallis 1y ago
    > but it's silly to act like it's a paragon of stability in the kernel. And it's dishonest to act like bugs from 15 years ago justify present-tense claims that it is constantly eating people's data and is a bad joke. Nobody's arguing that btrfs doesn't have a past history of data loss, more than a decade ago; that's not what's being questioned here.
    - AaronFriel 1y ago
      There's no need to call someone pointing out instability of a filesystem dishonest. That's bad faith. I don't get why folks feel the need to come out and cheer for a tool like this, do you have skin in the game on whether or not btrfs is considered stable? Are you a contributor? I don't get it. But since you asked - let me find some recent bugs. 5.15.37 - fixes data corruption in database reads using btrfs https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.37 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.... 5.15.65 - fixes double allocation and cache corruption https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.65 https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.... 6.1.105 - fixes O_APPEND with direct i/o can write corurpted files https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.105 https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... 6.1.110 - fixes fsync race and corruption https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.110 https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... 6.2.16 - fixes truncation of files causing data corruption https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.16 https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.1... btrfs-progs 6.2 fixes corruption on zstd extent read https://btrfs.readthedocs.io/en/latest/CHANGES.html https://btrfs.readthedocs.io/en/latest/CHANGES.html 6.15.3, 4: possible data corruption, seems to be reparable: https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix Are people that encountered these also dishonest?

gdgghhhhh 1y ago

It's amazing how many of the "experts" here don't get that bcachefs != btrfs

arccy 1y ago
people understand they're different, but if bcachefs is out, then that leaves btrfs as the only modern in-tree filesystem, but apparently you can't trust it with important data either.
- zitsarethecure 1y ago
  I've been using btrfs on my NAS for years and have not had any problems. I suspect there are a hell of a lot of people like me you will not hear about because people don't generally get as vocal when things just work.
  - aaronmdjones 1y ago
    The venn diagram of "people who want a modern copy-on-write filesystem with snapshots to manage large quantities of data" and "people who want a massive pool of fault-tolerant storage" (e.g. building a NAS) has some pretty significant overlap. The latter is where BTRFS is still hobbled: While the RAID-0, RAID-1, & RAID-10 modes work absolutely fine, the RAID-5 & RAID-6 modes are still broken, with an explicit warning during mkfs time (and in the manpages) that the feature is still experimental and should not be used to hold data that you care about retaining. This has, and continues to, bite people, with terabytes of data loss (backups are important, people!). That then sours them on every other aspect of ever using BTRFS again.
    - procaryote 1y ago
      If you ignore explicit warnings at mkfs time and then get upset the warning was accurate, you can't really fully blame the file system for it. Just raid on a lower layer and btrfs on top.
      - 1y ago

classified 1y ago

[flagged]