Assuming all goes well with the introduction of bcachefs into kernel 6.7; would the team be interested in accepting work that adds bcachefs as a secondary support file system?
Feature wise bcachefs and btrfs are comprable at the moment, and they should converge in the future. So at a higher level this addition should not add a lot of discrepencies in the UX.
@RlndVt Hello there.
Re:
Probably not. We are designed from the ground up to acomodate btrfs and it’s ‘ways’. It would be an extremely non-trivial endeavour to incorporate another filesystem. Yes, there is a similarity in the highest level analysis of capabilties: but that is where the similarity ends from my limited knowledge. There is an English expression “The devil is in the detail” that is extremely pertinent expression when 'adding another fs" comes to mind. As I understand it, which is not very well mind, every element of the basis of who bcachefs works is different from btrfs. This would mean a complete and parallel disk/vol/subvol/clone/snapshot support code re-write. Plus I’m no convinced yet that bcachefs does actually have parallel capabilities: it is decades behind btrfs in it’s development: and has massively fewer contributors.
However: In our transition from CentOS to openSUSE (many years ago now) we found some very deep bugs based on assumptions made from the projects inception… Theoretically adding an almost parallel capabilities filesystem to btrfs could potentially improve our code quality: if accepted and adopted by the entire coding contribution team (which is very small I might add). Plus we have a little bit of a mess remaining regarding our system drive and it’s use of btrfs-in-partition. Where-as our btrfs-in-partition for data pools (non system pool) has since been much improved and simplified.
So at least for me, as the co-maintainer along with @Flox, it would definitely be a far outside possibility, but not a complete inpossibility. My main concern would be an initial buggy contribution that then soils the project from then on and for ever as no other person then cares for the contributed code. Being a small but dedicated team, such an addition could basically kill the project if done poorly with zero commitment other than “here’s the first draft - the rest is up to you: and on, and on for ever”. We simply don’t have the human resources to take on any more that what we currently manage. But if a skilled and dedicated coder were to commit to such an endeavor, and persist with the work to better our game to abstract lots of special cases we currently manage just fine with, then dandy. But this would be an non trivial endeavour and I would not accept anything that had fewer tests than we currently have for our current capabilities.
So in short it would likely triple our support and development load: but there really is no other filesystem close to btrfs (ZFS has not block pointer re-write, where as I believe bcachefs does). And in that context, and based on the experience from the OS change we did, it could be a good thing. And it may attract coding talent, or those with the will to learn and help. And I can only agree to that.
So as you see, I’m in two minds, but if such an effort was undertaken the bcachefs option would have to be labeled very clearly as development only, and have clear warnings against its use. In the context of how long btrfs has taken to mature, and it’s time within the kernel to date (many years longer than the zero of bcachefs) it would, in my opinion, have to be a very clear “experiments” feature: And very likely disabled by default with some very serios warnings until end-to-end test coverage and some serious communit testing was in place before such a default was changed.
And before any other filesystem suggestion are put forward here. The answer from my corner is “NO”. Bcachefs is the sole filesystem that I would even consider accepting merges for. And then only if there was, as indicated above, some considerable benefit to the project and a concerted and enduring effort from likely newer contributors to up-our-game such that we could even acomodate this. We are a 10 + year old project now, and have only just now come-of-age. If poor developer interest followed such an addition I would not hesitate to wipe it from existence. We have waited around a decate for any interest what-so-ever to our fledgling ZFS: just saying. But that predates my ‘watch’ and that single file should be wiped by the next person to discover it. There have been zero to date.
So ideas are cheap and we are a very well established (in btrfs) NAS that could very well benefit from such an addition (but no other filesystems are welcome I’ll just add again). Simply because bcachefs does have some wider community interest, and if it also does have parallel capabilities then dandy. But again this would not be a trivial afair. But could end-up benefiting our code quality and attracting more talented developers. Which is my main concern really: in the context of maintaining our hopefully improving quality over-all. But only if there really is parallel capabilities. That is essential. Many of our users are here because we make stuff simple (we could do better with more talent). An entire parallel implementation that has subtle and strange differences would definitely harm the project - and potentially put us back years.
I hope so:
The UX or more the UI is the lease of it. Keep in mind we look a lot simpler that we actually are :). But we are working on simplifying things as we move forward, and have made some significant strides in that direction in recent years.
So if this is a passion of yours, or of someone who reads this. Then great: and don’t be put off by my reservations. But the core development team in this doocracy is already stretched. And it is all we can do to handle (and actively reduce - not increase) what we currently just about manage to do. But if folks, and some of the current core contributors, are interested then dandy. But this is not a thumbs up type thing. We need hard code contribution and accompanying testing to prove no regressions etc. There would very likely also be a need for some non destructive enhancements to our code code to acomodate all these. But again: this could be good for the project. But how-ever many thumbs-up is worth nothing without thought and action, and likely persistent participation.
And note again, no other fs has ever been considered on my watch and I would not personally back the addition of any other fs, and I’m currently extremely reluctant to adopt bcachefs even. But again it is the only other one I would consider at all. But the work would be massive and likely the bulk of it not performed by the current team. And if it became abandoned, then it would be wiped.
Hope that helps, at least for some context.
Thank you for your extensive reply! I can fully understand the extent of your reservations; and I would not want to introduce something that is harmful to the project in the long run.
You are right, at this point it is a cheap idea; some wishful thinking perhaps.
Thanks again for your response.