Bcachefs File-System Plans To Try Again To Land In Linux 6.6

[kreijack]

If you actually read the mailing list, it's not being rejected for because of the technical points being outlined.

Rather the reasons for rejecting this boils down to

• politics
• concerns about Kent being bud factor
• The current fs code in Linux apparently being a bit of a mess and this merge request is triggering people's concerns about the mess of this generic fs code
• For an optimal bcachefs merge some other kernel specific changes are needed

What you wrote is incorrect. There is interest to merge bcache. Even a BTRFS developer ( Josef Bacik) showed interested in this merge.

*concerns about Kent being bud factor Yes Kent sometime was too combative, but this is not the real problem (or almost it is not alone in this behavior). The real problem was that he fight for the "wrong battles". More below,

The current fs code in Linux apparently being a bit of a mess... To me it seems good to ask to not increase the complexity of the already existing code

For an optimal bcachefs merge some other kernel specific changes are needed General speaking, it was not the problem, of course there are some concerns about some specific change, and it was suggested to Kent to work to accept the preparatory patches and THEN to do the pull request for the bcachefs that at this time should be self-contained.
The "wrong battle" above is related to the preparatory patches. Even reiserfs-v4 had the same faith: it had to left some features outside the pull request to allow the merge. It was very promising, but then when the developer disappeared there was nobody (with the exception of few people) that worked on it. Ted Ts'o remembered that even btrfs was self contained when merged in linux.

The really points are:
- linux is not anymore an hacking camp where every one can do whatever they want, but is an industrial asset over which there is multi-million dollar business. So now it is not enough that the project is near interesting to touch some area. And to me it is sane to be a bit conservative in some area
- bcachefs has to prove its value: yes it raises interest but in the actual state it is far for to be a killer application. Nobody uses it, so it is unknown when happen when it will be used by thousand peoples. What everyone expect is that a lot of bugs bubble up (this is not a problem it is only the natural path to develop). To me this is the major concern; now the landscape is very different from when zfs appeared; at that time having a an integrated volume manager supporting different raid profile and the snapshot capabilities was enough. Today these are the minimum requirements for a new filesystem; moreover zfs and btrfs showed to be very complex and require dedicate team to maintain; and even so their develop speed decreased a lot, focusing on the improving the reliability.
The widespread adoption of the SSD decrease the importance of the tiering (which is one of the biggest advantage of bcachefs). And bcachefs still doesn't have a valid equivalent of raid5/6 implementation like btrfs.
All these things means that bcachefs is promising but it is not far better than btrfs or zfs (from a capabilities point of view) and it has to prove to satisfy the expectation.
Good or bad btrfs and zfs have their teams that worked on them, and it is not clear if someone will pay for a bcachefs team.

All the points above don't prevent the merging of bcachefs; these only make the merging less interesting from the other developers point of view. It is up to Kent to work with they to lower the barrier to the merge. It is possible and a "lower profile" will simplify the process. Then when bcachefs will be merged and will be able to proof their capabilities it will be allowed to Kent to make more invasive changes.

[mdedetrich]

What you wrote is incorrect. There is interest to merge bcache. Even a BTRFS developer ( Josef Bacik) showed interested in this merge.

*concerns about Kent being bud factor Yes Kent sometime was too combative, but this is not the real problem (or almost it is not alone in this behavior). The real problem was that he fight for the "wrong battles". More below,

The current fs code in Linux apparently being a bit of a mess... To me it seems good to ask to not increase the complexity of the already existing code

For an optimal bcachefs merge some other kernel specific changes are needed General speaking, it was not the problem, of course there are some concerns about some specific change, and it was suggested to Kent to work to accept the preparatory patches and THEN to do the pull request for the bcachefs that at this time should be self-contained.
The "wrong battle" above is related to the preparatory patches. Even reiserfs-v4 had the same faith: it had to left some features outside the pull request to allow the merge. It was very promising, but then when the developer disappeared there was nobody (with the exception of few people) that worked on it. Ted Ts'o remembered that even btrfs was self contained when merged in linux.

The really points are:
- linux is not anymore an hacking camp where every one can do whatever they want, but is an industrial asset over which there is multi-million dollar business. So now it is not enough that the project is near interesting to touch some area. And to me it is sane to be a bit conservative in some area
- bcachefs has to prove its value: yes it raises interest but in the actual state it is far for to be a killer application. Nobody uses it, so it is unknown when happen when it will be used by thousand peoples. What everyone expect is that a lot of bugs bubble up (this is not a problem it is only the natural path to develop). To me this is the major concern; now the landscape is very different from when zfs appeared; at that time having a an integrated volume manager supporting different raid profile and the snapshot capabilities was enough. Today these are the minimum requirements for a new filesystem; moreover zfs and btrfs showed to be very complex and require dedicate team to maintain; and even so their develop speed decreased a lot, focusing on the improving the reliability.
The widespread adoption of the SSD decrease the importance of the tiering (which is one of the biggest advantage of bcachefs). And bcachefs still doesn't have a valid equivalent of raid5/6 implementation like btrfs.
All these things means that bcachefs is promising but it is not far better than btrfs or zfs (from a capabilities point of view) and it has to prove to satisfy the expectation.
Good or bad btrfs and zfs have their teams that worked on them, and it is not clear if someone will pay for a bcachefs team.

All the points above don't prevent the merging of bcachefs; these only make the merging less interesting from the other developers point of view. It is up to Kent to work with they to lower the barrier to the merge. It is possible and a "lower profile" will simplify the process. Then when bcachefs will be merged and will be able to proof their capabilities it will be allowed to Kent to make more invasive changes.

I think you mistook the intention if my post and the context. My post was responding to someone else who was claiming that what I said earlier was wrong and he used the current merging concerns of btrfs as evidence of that post.

The whole point behind my post is just stating that while there may concerns, they were largely not technical and has not that hard to address.

[mdedetrich]

Politics? What kind of politics? Politics shouldn't influence Linux kernel development, but purely technical merits.

I don't get what you mean by "bud factor ". If it's about weed, that's not so bad. I consider it a personal option and shouldn't influence Bcachefs technical merits. It shouldn't if it were something worse, anyway.

If filesystem code in Linux kernel is a mess, it should be improved instead crying about it because adding another filesystem.

What other kernel changes are needed that are so important right now?

I spent like an hour reading all of the LKML threads and there is definitely politics/ego factors going on there.

Also I meant bus factor, that was a typo.

[timofonic]

I spent like an hour reading all of the LKML threads and there is definitely politics/ego factors going on there.

Also I meant bus factor, that was a typo.

Something smells bad in LKML, it seems.