upvote
> 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. :-/

reply
> 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.

reply
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.

reply
btrfs has one critical issue they don't fix: it blocks access to fs for minutes if you remove large files. I am not sure how this is acceptable for prod grade fs..
reply
> it blocks access to fs for minutes if you remove large files.

How large is large? I've deleted files with sizes of tens to hundreds of GBs and not seen that, and can probably whip up a test with a single-digit TB file if motivated.

Do you perhaps have 'discard=sync' in your mount options, or are using a kernel earlier than 6.2, which is the version -according to the docs- where async discard became the default?

reply
Only if you have quotas enabled IIRC.
reply
> 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.

reply
Came here to say this. Supposedly Fedora also considers giving up on it.
reply
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.

reply
Meta doesn't have anyone working on btrfs anymore, it appears to be two guys at SuSE and drive bys.
reply
Not true, Boris Burkov from Meta works on btrfs. And two people from WDC.
reply
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.

reply
Just pleases try to get it back into mainline.
reply
> There was never a clear statement on what the issue was. What you guys got in public was about as much as I got.

If you are referring to why bcachefs was removed from the Linux kernel, here's a discussion on bcachefs being removed from the Linux kernel.

https://news.ycombinator.com/item?id=44868868

reply
I'd like to point out that HN user koverstreet was involved in those threads, here.

They already know what was discussed.

(Good? Bad? Indifferent? I don't know and I don't have a dog in this race. I'm just here connecting the dots.)

reply