We can always say "yes, this is fixed in master, this is fixed in 6.XX-rc4" but it is still experimental and tends to be what causes the most pain right now. I think this needs to be communicated more clearly. If the filesystem goes off experimental, I think a subset of features should be gated by filesystem options to reduce the need for big and urgent rc patches. The problem is... when the experimental label is removed, it needs to be very clear that users aren't expected to be running the latest rc and master branch. All the features marked as stable should have settled enough that there won't be 6 users requiring a developer to mount their filesystem read-write or recover files from a catastrophic race condition. This is where communication needs to be clear, bcachefs website, tools, options; should all clearly label features that might require someone to ask a developer's help or to run the latest release candidate or a debug version of the kernel. Bcachefs has very nice unit and integration testing with ktest, but it isn't enough to represent real-world usage yet and that's why I think some features should still be marked just as experimental as erasure coding. Bcachefs filesystem where I do not use reflink, snapshot or anything wild, only multiple devices with foreground/promote_target, replication, compression, never experience weird issues or lockups for many kernel versions now. Mind you, I'm not using bcachefs on any rootfs yet, only specific use-case and patterns that can be documented. I care about the future and success of bcachefs to be my go-to filesystem for anything that requires CoW features, robust repair tools, caching and flexible RAID-like features. I just don't want it to get kicked out of the kernel because of huge changesets to fix bugs on features that shouldn't be used by someone who expects the filesystem to behave. It might slow down development a bit to mark some features as experimental, but it'll remove the pressure of having to push so many bug fixes that are critical to make sure users don't experience critical failures or blindly try to repair their FS using fsck -y without reporting issues. It reduces the experimental surface to a subset of features, it also makes the user aware of what they should do if enabled, eg.: contact dev before fsck -y, run a recent kernel at all time, etc. One more thing that I think is missing, many patches submitted, even if it doesn't show up, should have a Reported-By and Tested-By tag to help show how many people in the community are working and helping make Bcachefs great, it would also make people on the ML aware that patches aren't just thrown in there; it usually has been a reported bug from a community member which had to test the resulting patch. Anyway, that message is bigger than I expected and I hope brings some light on how I perceive bcachefs from a user standpoint. Have a great weekend! On Fri, Jun 20, 2025 at 8:15â?¯PM Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > On Fri, Jun 20, 2025 at 07:35:04PM -0400, Kent Overstreet wrote: > > So it's hard to fathom what's going on here. > > I also need to add that this kind of drama, and these responses to pull > requests - second guessing technical decisions, outright trash talk - > have done an incredible amount of damage, and I think it's time to make > you guys aware of that since it's directly relevant to the story of this > pull request. > > I've put a lot of work into building a real community around bcachefs, > because that's critical to making it the rock solid, dependable > filesystem, for eeryone, that I intend it to be: building a community > where people feel free to share observations, bug reports, and where > people trust that those will be acted on responsibly. > > That all gets set back whenever drama like this happens. Last time, the > casefolding bugfix pull request, ignited a whole vi. vs. emacs holy war. > Every time this happens, the calm, thoughtful people pull back, and all > I hear from are the angry, dramatic voices. > > More than that, I lost a hire because of Linus's constant, > every-other-pull-request "I'm thinking about removing bcachefs from the > kernel". It turns out, smart, thoughtful engineers with stable jobs > become very hesitant about leaving those jobs when that happens, and > that's all their co-workers are seeing. > > And the first thing that got cancelled/put aside because of that - work > that was in progress, and hasn't been completed - was tooling for > comprehensive programatic fault injection for on disk format errors. > IOW - the tooling and test coverage that would have caught the subvolume > deletion bug. > > That's a really painful loss right now. > > Even despite that, bcachefs development has been going incredibly > smoothly, and it's shaping up fast. Like I mentioned before, 100+ TB > filesystems are commonplace, users are commenting every release on how > much smoother is getting. We are, I hope, only a year or less from being > able to take the experimental label off, based on the decline in > critical bug reports I'm seeing. > > The only area that gives me cause for concern - and it causes a _lot_ of > concern - is upstream. >
