No. His code, testing methods, and submitting code that broke both testing and basic construct was the issue.
You can dance all day around the issue, but a developer who can’t get a fairly simple bit of code in good enough order to submit for upstream, THEN can’t even test to make sure it doesn’t break AT, THEN N is also behind deadline, THENNNNN is also a huge dick about it…not a good developer.
All he had to do was not completely shit the bed, and he did it repeatedly. THOUSANDS of other developers interact with that same list and upstream code on a weekly basis. This guy’s code and methods is shit, and deserved to have his code kicked out. He’s a terrible developer, and I wouldn’t trust his code to wipe with.
Oh, okay, lazy guy. This is the pedants way of stomping their feet because they refuse to read the obvious that is already out there, you know. Go ahead and be a lil baby because your point is wrong.
Despite this, it has become clear that BcacheFS is rather unstable, with frequent and extensive patches being submitted to the point where [Linus Torvalds] in August of last year pushed back against it, as well as expressing regret for merging BcacheFS into mainline Linux. As covered in the video, [Kent] has pushed users reporting issues to upgrade to the latest Linux kernel to get critical fixes, which really reinforces the notion that BcacheFS is at best an experimental Alpha-level filesystem implementation and should probably not be used with important data or systems.
It’s unstable because it’s a new file system, not because the guy is a shit programmer. Did you even read your second link? It repeats the exact reason we’ve all tried to tell you, that it was removed because Kent keeps releasing new features during release candidate period.
Also, I don’t get why you can’t discuss things in a civil manner. Is this why you keep insisting that Kent’s project is not being removed because of his attitude, but because of his lack of skill? Are you scared of admitting that your attitude will one day get you treated the same way as Kent’s does?
An inspirational reply of koverstreet https://lwn.net/Articles/1028572/ He is focused on solving all bug reports, and in iterating bcachefs in the faster way possible. It is a sort of implicit contract with its users base: “you are using bcachefs in production/real-world despite it is experimental, and I will support you restoring files and improving code”.
So, I can understand why he doesn’t like waiting too much before releasing improvements. The Linux kenernel release cycle can transform weeks in months if some bug-fixes requires new features or refactorings, like in case of a new file system. I’m sorry that him and Linux maintainers didn’t find a good approach.
BTW, I used bcachefs for 1-2 years with 3 HDD and 1 SSD in cache. It supported this usage scenario better than ZFS for a desktop/workstation like mine setting.
Bcachefs was not kicked out because its design and implementation is of bad quality. A bad quality software is something that is: full of bugs; every 4 fixed bugs you introduce a new one; the design is so wrong that it is difficult to add new features; the code is difficult to understand.
If you consider various metrics like irrecoverable loss of data, lines of code, features, Bcachefs is a very good project. It is under development, so the source code is not “stable” and there are frequent updates, but the behavior of the file system is fully under control and it is only improving,
Bcachefs seems a really well designed filesystem, because it takes in consideration the lessons learned from other filesystems and its code base is compact and elegant.
It is also very robust because corrupted metadata can be reconstructed scanning the leaf nodes with data. So there are very few weak points in case of disasters. Infact every time there were a report of corrupted data, the bcachefs team was able to fix the code and retrieve the data of the affected users.
I used it for a while, and I were impressed. For example it automatically upgrade its data structures.
It is true that there were a commit of bcachefs that broken the kernel build, because in conflicts with others commits. But this can happen: it is not strictly related to the quality of code of bcachefs, but more to the interaction with other developers, that up to date it is the weak point of the project.
No. His code, testing methods, and submitting code that broke both testing and basic construct was the issue.
You can dance all day around the issue, but a developer who can’t get a fairly simple bit of code in good enough order to submit for upstream, THEN can’t even test to make sure it doesn’t break AT, THEN N is also behind deadline, THENNNNN is also a huge dick about it…not a good developer.
All he had to do was not completely shit the bed, and he did it repeatedly. THOUSANDS of other developers interact with that same list and upstream code on a weekly basis. This guy’s code and methods is shit, and deserved to have his code kicked out. He’s a terrible developer, and I wouldn’t trust his code to wipe with.
Damn, they downvote truth… Another of herd mentality moments
Yuuuup. Newb fanboys.
Again, please post proof of what you’re saying here. All I’ve seen from this issue had been his problematic attitude, not his code quality.
Oh, okay, lazy guy. This is the pedants way of stomping their feet because they refuse to read the obvious that is already out there, you know. Go ahead and be a lil baby because your point is wrong.
https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesystem-stability-controversy/
Literally describes the same behavior here from a different time period: https://www.theregister.com/2025/07/01/bcachefs_may_get_dropped/
It’s unstable because it’s a new file system, not because the guy is a shit programmer. Did you even read your second link? It repeats the exact reason we’ve all tried to tell you, that it was removed because Kent keeps releasing new features during release candidate period.
Also, I don’t get why you can’t discuss things in a civil manner. Is this why you keep insisting that Kent’s project is not being removed because of his attitude, but because of his lack of skill? Are you scared of admitting that your attitude will one day get you treated the same way as Kent’s does?
Pathetic 🤣
It’s like you’re a wannabe a troll, but you’re incapable of really hammering home the pendantic nature of facile incel ricochet insults.
Whenever you want to give up and admit you’re wrong, I’ll be here ignoring you.
Unfortunately, the troll here is the one who can’t be bothered to read people’s comment before replying. Try again.
An inspirational reply of koverstreet https://lwn.net/Articles/1028572/ He is focused on solving all bug reports, and in iterating bcachefs in the faster way possible. It is a sort of implicit contract with its users base: “you are using bcachefs in production/real-world despite it is experimental, and I will support you restoring files and improving code”.
So, I can understand why he doesn’t like waiting too much before releasing improvements. The Linux kenernel release cycle can transform weeks in months if some bug-fixes requires new features or refactorings, like in case of a new file system. I’m sorry that him and Linux maintainers didn’t find a good approach.
BTW, I used bcachefs for 1-2 years with 3 HDD and 1 SSD in cache. It supported this usage scenario better than ZFS for a desktop/workstation like mine setting.
Bcachefs was not kicked out because its design and implementation is of bad quality. A bad quality software is something that is: full of bugs; every 4 fixed bugs you introduce a new one; the design is so wrong that it is difficult to add new features; the code is difficult to understand.
If you consider various metrics like irrecoverable loss of data, lines of code, features, Bcachefs is a very good project. It is under development, so the source code is not “stable” and there are frequent updates, but the behavior of the file system is fully under control and it is only improving,
Bcachefs seems a really well designed filesystem, because it takes in consideration the lessons learned from other filesystems and its code base is compact and elegant.
It is also very robust because corrupted metadata can be reconstructed scanning the leaf nodes with data. So there are very few weak points in case of disasters. Infact every time there were a report of corrupted data, the bcachefs team was able to fix the code and retrieve the data of the affected users.
I used it for a while, and I were impressed. For example it automatically upgrade its data structures.
It is true that there were a commit of bcachefs that broken the kernel build, because in conflicts with others commits. But this can happen: it is not strictly related to the quality of code of bcachefs, but more to the interaction with other developers, that up to date it is the weak point of the project.