6 ms·
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
by 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 agoWhat 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 agoI think a lot of people interested in bcachefs were people who had lost faith in btrfs.
- pfexec 1y agoBecause 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.
- newZWhoDis 1y agoSynology exclusively uses BTRFS afaik, and there aren't widespread stories of data loss with their products.
- pfexec 1y agoTook 10 seconds to find: https://philip.greenspun.com/blog/2024/02/29/why-is-the-btrfs-file-system-as-implemented-by-synology-so-fragile/ https://philip.greenspun.com/blog/2024/02/29/why-is-the-btrf... > We had a few seconds of power loss the other day. Everything in the house, including a Windows machine using NTFS, came back to life without any issues. A Synology DS720+, however, became a useless brick, claiming to have suffered unrecoverable file system damage while the underlying two hard drives and two SSDs are in perfect condition. It’s two mirrored drives using the Btrfs file system
- zejn 1y agoSynology does not use vanilla btrfs, they use a modified btrfs that runs over mdraid mirror, which somehow communicates with btrfs layer to supposedly fix errors, when they occur. It's not clear how far behind that fork is.
- ksec 1y agoSynology are still shipping kernel 5.10 on their latest model. And 4.4 only a few years prior. I am hoping we will get ZFS from Ubnt NAS via update.
- mdedetrich 1y agoThats because they use mdadm for the RAID, the btrfs sits underneath a virtual mdadm volume ;)
- accelbred 1y agoAFAIK, Facebook uses BTRFS on their servers.
- slashdave 1y agoIsn't OpenSUSE still shipping with btrfs on by default?
- thereisnospork 1y agoThe rolling "tumbleweed" variant does, afaict there aren't many issues related to btrfs[0]. Most problems I see seem to be Nvidia drivers or something choking during the update process (bad mirrors, odd package not updating, etc.). [0]I'm currently evaluating OpenSuse as a possible W11 replacement, but not using it for anything serious atm.
- yjftsjthsd-h 1y agoI used to run tumbleweed with btrfs, then it lost its root filesystem twice, now I distrust btrfs.
- commandersaki 1y agoNo encryption, and I really don't want to do LUKS gymnastics.
- TwoNineFive 1y agoWhy don't you know anything about the history of btrfs? You would know if you knew anything, so why don't you know?
- webstrand 1y agoI am also a Patreon supporter, and I intentionally didn't switch to bcachefs until it was merged into the kernel. After all, Linus would never break userspace right? I am also frustrated by this whole debacle, I'm not going to stop funding him though Bcachefs is a solid alternative to btrfs. It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? I really wish, though that DKMS was not such a terrible a solution. It _will_ break my boot, because it always breaks my boot. The Linux kernel really needs a stable module API so that out-of-tree modules like bcachefs are not impossible to reliably boot with.
- stycznik 1y ago>It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? This isn't just a one time thing, speaking as someone who follows the kernel, apparently this has been going on pretty much since bcachefs first tried to get into Linus's tree. Kent even once told another kernel maintainer to "get your head examined" and was rewarded with a temporary ban. Edit: To be fair, the kernel is infamous for being guarded by stubborn maintainers but really I guess the lesson to be learned here is if you want your pet project to stick around in the kernel you really can't afford to be stubborn yourself.
- danw1979 1y ago> I guess the lesson to be learned here is if you want your pet project to stick around in the kernel you really can't afford to be stubborn yourself. Amen. And to your point about it being a "pet project" - I'm sure I could go look at the commit history, but is anyone other than Kent actually contributing meaningfully to bcachefs ? If not, this project sorely needs more than one person involved.
- LeFantome 1y ago> this project sorely needs more than one person involved. I hold out some hope that somebody else will get involved in bcachefs and that the new person will be able to resubmit bcachefs to the mainline. My impression is that many people respect the technology and would be happy to have it back--they just cannot work with Kent. But that is the reasons this will probably not happen. It does not appear that anybody wants to work with Kent.
- thayne 1y ago> I _really_ wanted Linux to get a native, modern COW filesystem Doesn't btrfs fit that description? I know there are some problems with it, but it is definitely a native COW filesystem, abd AFAIK it is "modern".
- webstrand 1y agoBtrfs has a "happy path" so long as you don't use any features outside of the happy path, your data will generally be fine. Outside of that, your data is less reliably fine. Btrfs also has issues with large numbers of snapshots, you have to cull them occasionally or things begin to slow down, bcachefs does not.
- teiferer 1y ago> I _really_ wanted Linux to get a native, modern COW filesystem Btrfs not good? (Honest question.)
- rrauenza 1y agoI've been using btrfs for maybe 10 years now? -- on a single Linux home NAS. I use it in a raid1c3 config (I used to do c2). raid1cN is mirroring with N copies. I have compression on. I use snapshots rarely. I've had a few issues, but no data loss: * Early versions of btrfs had an issue where you'd run out of metadata space (if I recall). You had to rebalance and sometimes add some temporary space do that. * One of my filesystems wasn't optimally aligned because btrfs didn't do that automatically (or something like that -- this was a long time ago.) A very very minor issue. * Corruption (but no data loss, so I'm not sure it's corruption per se...) during a device replacement. This last one caused no data loss, but a lot of error messages. I started a logical device removal, removed the device physically, rebooted, and then accidentally readded the physical device while it was still removing it logically. It was not happy. I physically removed the device again, finished the logical remove, and did a scrub and the fsck equivalent. No errors. I think that's a testament to its resiliency, but also a testament how you can shoot yourself in the foot. I've never used RAID5/6 on btrfs and don't plan to -- partly because of the scary words around it, but I also assume the rebuild time is longer.
- bravetraveler 1y agoFunny to hear your success; I've managed to break almost every mirror I've entrusted to BTRFS! How? Holding down the power button! Seemingly regardless of the drives, interface, or kernel, other filesystems paired with LVM or mdraid fail/recover/lie more gracefully. NVMe or SATA (spindles). Demonstrated back-to-back with replacements from different batches. Truly disheartening, I want BTRFS. I would like to dedicate some time to this, but, well, time remains of the essence. I'm hoping it's something boring like my luck with boards/storage controllers, /shrug.
- nolist_policy 1y ago
- koverstreet 1y ago> 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. And every time something like this comes up, I end up with every sort of accusation pointed at me, and no one seems to be willing to look at the wider picture - why is the kernel community still unable to figure out a plan to get a trustworthy modern filesystem? > This is your problem to fix. No, I've said from the start that this needs to be a community effort. A filesystem is too big for one person. Be realistic :) If the community wants this to happen, the community will have to step up.
- danw1979 1y agoLook, if you're here saying "the throwaway comments aren't me" then I beleive you. It'd be nice if you said that clearly though. Please please don't forget I want you to succeed - that's why I bunged nearly $800 your way in this endeavour - but I'm not the only person who thinks you come across as completely immune to critisicm, even when it's constructive and from your supporters. >> This is your problem to fix. > No, I've said from the start that this needs to be a community effort. A filesystem is too big for one person. Right now that "community effort" is looking a bit unlikely, eh ? I would hate to have to deal with these people as my primary occupation and I totally get why you don't want to continue. That's said, nobody else has the power, skill or inclination to make bcachefs that wonderful filesystem of the future for Linux - only you. That's what I meant by "this is your problem to fix". I wish you the best of luck with the new DKMS direction. And I'll get on board and actually try it out soon :D
- koverstreet 1y ago> Please please don't forget I want you to succeed - that's why I bunged nearly $800 your way in this endeavour - but I'm not the only person who thinks you come across as completely immune to critisicm, even when it's constructive and from your supporters. You have to understand, I get an absolute _ton_ of "constructive criticism" from people who basically are assuming everything is going off the rails and are expecting massive, and unrealistic changes; for bandwidth reasons if nothing else. I have to stay focused on the code and getting it done. > Right now that "community effort" is looking a bit unlikely, eh ? Actually, the big surprise from the DKMS switch is just how much the community came together to make it happen. This project has looked like a one man show for a long time, and the core of it probably always will be for the simple reason that there are precious few people with the skillset required to do core filesystem engineering; that requires a massive amount of dedication and investment of time to get good at, there's a hell of a learning curve. But there's still a lot of people with the willingness and ability to help out in other areas. People have been since even before the DKMS switch, to be honest, it's just that a lot of it is boring invisible but extremely necessary QA work - and that stuff is work, and people have helped out a lot there. You have to be involved in the community, in the IRC channel to see this stuff going on. It's really not just me. And now with the DKMS switch, a lot more people jumped in and started helping, and that's how we were able to get every major distro supported before the 6.17 release. That happened _fast_, and only a small fraction of the work was mine, mostly I was just coordinating. Honestly, looking back, I don't think I could have planned this better - the timing was perfect. We're nearly done with stabilization, so it was the right time to start focusing more on distro integration and building up those working relationships, and the DKMS migration was just the kick in the pants to make that happen. Now we're pretty well positioned to get bcachefs into distro installers perhaps six months out. The community is real, and it's growing. (I would still _fucking love_ to have more actual filesystem engineers though, heh).