That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.

In fact they delivered the erasure coding for parity raid back in march this year.

The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I can only tell you that mixing different device tiers and having a per-file/directory replication setting is a god send specially in these times where storage costs more than gold.

▲

tarruda 3 hours ago | parent | next [-]

> The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is.

I'm pretty sure Bcachefs is amazing and better than Btrfs. I also think Zfs is amazing and better than Btrfs. Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.

> That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.

A better approach might have been to just paused mainline merging instead of forcing being kicked out?

Eg "Hey Linus, Bcachefs is still in early development and I need to merge changes in a pace that is not compatible with Linux development process. So I'm going to pause for a while now and once it reaches maintenance status I will focus on submitting patches in a healthy pace that you can digest".

▲

nvme0n1p1 2 hours ago | parent | next [-]

> Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.

100%. My system is rock solid and the last thing I need is rolling the dice after every update on whether my system will boot. https://www.reddit.com/r/archlinux/comments/eywcp7/linux_551...

I'm impressed with bcachefs's accomplishments though, and if they ever reconcile with the kernel I'll surely give it a fair shake.

	▲	koverstreet 34 minutes ago \| parent [-]
		bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has. Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.

▲

ssl-3 an hour ago | parent | prev | next [-]

> I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.

I used to think that about ReiserFS, too. It was in the mainline kernel, development was snappy, and it solved some performance problems. I used it all over the place.

Things then subsequently... changed. :-/

▲

doubled112 an hour ago | parent | prev | next [-]

> I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.

Except RHEL. They don’t include it in their kernels.

Alma Linux started including it again though.

It can never be easy.

▲

irusensei 2 hours ago | parent | prev | next [-]

I think in a perfect world they should had put someone in between to mediate and curate patches while providing DKMS for urgent patches.

As for BTRFS I think its also pretty good. Its just that I have the impression its development is guided by the needs of its sponsors and sadly for us META doesn't need RAID5.

	▲	koverstreet 2 hours ago \| parent [-]
		Meta doesn't have anyone working on btrfs anymore, it appears to be two guys at SuSE and drive bys.

▲

koverstreet 2 hours ago | parent | prev [-]

I was very up front about where we were at.

A lot of things were tried, people did try to mediate.

The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix.

There was never a clear statement on what the issue was. What you guys got in public was about as much as I got.

All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out.

I genuinely do not know what they were thinking.

▲

novafunc 2 hours ago | parent | prev [-]

bcachefs was already working at its own pace prior to being accepted in the kernel. It could have continued doing so for years until it was really "ready".

Instead it got kicked out because Kent constantly ignored the kernel's contribution rules and is unlikely it will ever be accepted back into the kernel.

▲

koverstreet 2 hours ago | parent | next [-]

I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere.

And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum.

A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up.

Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.

▲

pantalaimon 2 hours ago | parent [-]

You can't let Reddit guide your technical decisions.

The FS was marked experimental, so there is no urgency in fixing bugs or providing features in a certain cycle. Everyone using it knows what they got themselves into. You can still provide the DKMS module for faster fixes and features for anyone who wants to use BCacheFS more seriously for the time that the upstreaming process takes, but eventually it would have all been on mainline.

Asahi is taking a similar approach where they have their downstream kernel and push things upstream once they are mature.

That means the upstream kernel is not useful for running on that hardware now, but things are moving there eventually.

	▲	koverstreet 8 minutes ago \| parent [-]
		No urgency over fixing bugs? What do you think this is, btrfs? :) All this has been discussed to death, we don't need people armchair quarterbacking a year later. It's over, it's time to move on.

▲

irusensei 2 hours ago | parent | prev [-]

That would be a shame since there is nothing else over there with the same set of features. Disregarding drama, I'm telling you it’s that good.