Readit NewsHow does it look about long-term sustainability? Looking at the git history, ~97% of bcachefs commits are yours. What happens if you step back, burn out, or can't continue for any reason? Is there a fallback plan? A community or team that could realistically take over?
For anyone evaluating this for production use in a company, that's the question that matters most. A filesystem isn't a library you can swap out — you're locked in for years. The technical quality can be excellent and it still won't pass a risk assessment if it depends on a single person.
And the sustainability equation just changed dramatically, thanks to Claude.
I've been using it the past week for a lot of stuff, and I should really write something longer up, but suffice it to say that I'm impressed. It can't do much independently yet, but it's been able to handle a /lot/ of the grunt work - the other night I had it go through open Github issues, fix what it could and take notes on the rest, and I came back to 8 patches for actual bugs, all of them correct, with excellent commit messages. Holy shit, we're living in the future :)
It can't design for shit, it doesn't understand performance implications when writing code (I've noticed this repeatedly); most of how I'm using it is "pair programming". But I'm finally feeling like I'll be able to take a vacation in the near future and still keep up with everything.
Two other people are using it (with heavy review, actively telling it to go back and research topics more) for a big update to the Principles of Operations. Nice.
Basically, the sustainability aspect comes down to writing clean, maintainable, well documented code - and I think I've accomplished that. One holy shit moment the other day was watching Claude navigate /and understand/ btree and journalling code - and making the connection between the way I use assertions and linear typing/dependent typing. All those years spent on that code developing new ways of thinking about and using assertions to make that stuff practical for one person to do... it's paid off.
Beyond that, the real challenges are pushing the boundaries of how introspectable, understandable and transparent complex systems code can be for the end user - and bcachefs is pushing boundaries there. Making a habit of writing pretty printers for absolutely everything means that now our tracing is the best you'll see in software like this, and well integrated with 'bcachefs fs top'. The timestats stuff that I started well over a decade ago - we've now got a new 'bcachefs fs timestats' interface for that, which is already making debugging performance issues dramatically easier than it has been in the past.
This is gamechanging stuff :)
Quote from webpage: "The COW filesystem for Linux that won't eat your data"
Quote from webpage: "It's the job of the filesystem to never lose your data: anything that can be repaired, will be."
Quote July 2025: "I've been digging through the bug tracker and polling users to see what bugs are still outstanding, and - it's not much. So, the experimental label is coming off in 6.18."
I was a big fan of bcachefs and was looking forward to deploying it across ~100 machines in production. Unfortunately, the removal from the mainline kernel has seriously undermined its credibility for use within a company environment.
A filesystem needs time to mature, and that's fine — but the official webpage should clearly display a warning that this is still experimental and that its long-term support situation is uncertain. People evaluating it for production use deserve to know what they're getting into.
Would have loved to use it.
If you look at actual data - frequency of user impacting data loss bugs - bcachefs has been doing quite a bit better than other filesystems have /after/ they've dropped the experimental level.
We just live in the age of hype and overhype and excitement that turns into drama. Everyone just needs to chill out :)
And I don't hide stuff like this: compare the impact of the bug itself to what you'd see in other filesystems. We knew basically from the first report what caused it, were able to communicate to users what happened, it wasn't random, it wasn't silent data loss - error messages were good and it was able to understand what was going on.
Talk to people who are actually using it. I know of quite a few people who are now migrating from ZFS because they want something more reliable.
There do seem to be complex cells that allow association with a recognizable face, person, icon, object, or distinctive thing. Face cells apply equally to abstractions like logos or UI elements in an app as they do to people, famous animals, unique audio stings, etc. Split brain patients also demonstrate amazing strangeness with memory and subconscious responses.
There are all sorts of layers to human memory, beyond just short term, long term, REM, memory palaces, and so forth, and so there's no simple singular function of "memory" in biological brains, but a suite of different strategies and a pipeline that roughly slots into the fuzzy bucket words we use for them today.
Table; chair behind and little to the left of the chair; plant on table
Most people won't really have conscious access to all the details that we use in recognizing objects - but that is a skill that can be consciously developed, as artists and painters do. A non-artist would be able to identify most of the details, but not all (I would be really bad compared to an actual artist with colors and spatial relationships), and I wouldn't be able to enumerate the important details in a way that makes any kind of sense for forming a recognizable scene.
So it follows from that that our ability to recognize faces is not purely - or even primarily - an attribute of what we would normally call "memory", certainly in the sense of conscious memory where we can recall details on demand. Like you alluded to re: mammals and spaces, we're really good at identifying, categorizing, and recognizing new forms of structure.
It's an absolutely enormous problem, and I'm excited that it seems to be one of the primary research efforts kicking off this year. It could be a very huge capabilities step change.
What I see in my own domain I often recognize as superficially working but flawed in various ways. I have to assume the domains I am less familiar are the same.
It definitely eliminates a lot of tedium, but needs a lot of guidance if you want good results.
When Kia and Hyundai were recently selling models without real keys or ignition interlocks, that was the main thing folks did when they stole them.
It's risky, sure. But the garage situation also seems risky.
The people who work there aren't office workers; you've got blue collar workers who spend all day working together and hanging out using heavy equipment right in the back. And they're going to be well acquainted with the local tow truck drivers and the local police - so unless you're somewhere like Detroit, you better be on your way across state lines the moment you're out of there. And you're not conning a typical corporate drone who sees 100 faces a day; they'll be able to give a good description.
And then what? You're either stuck filing off VINs and faking a bunch of paperwork, or you have to sell it to a chop shop. The only way it'd plausibly have a decent enough payoff is if you're scouting for unique vehicles with some value (say, a mint condition 3000GT), but that's an even worse proposition for social engineering - people working in a garage are car guys, when someone brings in a cool vehicle everyone's talking about it and the guy who brought it in. Good luck with that :)
Dealership? Even worse proposition, they're actual targets so they know how to track down missing vehicles.
If you really want to steal a car via social engineering, hit a car rental place, give them fake documentation, then drive to a different state to unload it - you still have to fake all the paperwork, and strip anything that identifies it as a rental, and you won't be able to sell to anyone reputable so it'll be a slow process, and you'll need to disguise your appearance differently both times so descriptions don't match later. IOW - if you're doing it right so it has a chance in hell of working, that office job starts to sound a whole lot less tedious.
Way easier to just write code :)
So, if you think a project is too corporate, then fork it.
I'm using it for converting all of the userspace bcachefs code to Rust right now, and it's going incredibly smoothly. The trick is just to think of it like a junior engineer - a smart, fast junior engineer, but lacking in experience and big picture thinking.
But if you were vibe coding and YOLOing before Claude, all those bad habits are catching up with you suuuuuuuuuuuper hard right now :)