It's Looking Like Bcachefs Won't Be Merged For Linux 6.5

[phoronix]

Phoronix: It's Looking Like Bcachefs Probably Won't Be Merged For Linux 6.5

Today the Linux 6.5 merge window is expected to be closed and one of the lingering issues has been whether the BCacheFS file-system driver will be merged following its pull request having been finally sent in...

https://www.phoronix.com/news/Linux-6.5-Bcachefs-Unlikely

[lowflyer]

... so the bca chefs have more time for the cooking.

[timofonic]

I would like to see a summary. Reading LKML is difficult if you aren't used to it!

Can anyone summarize the discussion? It seems Kent had some differences with a few developers.

There's some people complaining sbout the non-bcachefs changes, as usual.

I would like Bcachefs getting mainlined and more talented developers get involved into this interesting filesystem.

[nadir]

I would like to see a summary. Reading LKML is difficult if you aren't used to it!

Can anyone summarize the discussion? It seems Kent had some differences with a few developers.

There's some people complaining sbout the non-bcachefs changes, as usual.

I would like Bcachefs getting mainlined and more talented developers get involved into this interesting filesystem.

I've just read all of it and I can't really add anything significant to your description.

It seems some of the drama has happened in other threads concerning the changes in other subsystems.

There's lots of finger pointing where it's difficult for me as an outsider to tell who's correct, as they're mostly referencing vaguely described past disagreements.

There's also some people showing strong support for Kent and Bcachefs' inclusion.

All in all, I also don't think it's likely it's gonna be included with 6.5. Linus still hasn't commented.

[skeevy420]

I hope it gets tunable compression levels some day since that's the one feature I'm missing from using it. AFAICT, Zstd is 3 by default and you have to patch the code to change that. Call me crazy, but I don't mind limiting some mount points to ~75mbps write speed for zstd-19, but at the same time I don't want to use that as default everywhere because it's slow as hell. ~70-80mpbs is what Steam reports writing when I'm downloading games onto my Steam game storage ZFS dataset that uses Zstd-19 on a 3x8TB RAID. If anyone is curious: ~200mbps write with LZ4 and it reads at ~400-500 regardless of LZ4 or Zstd (the only ones I use).

I'm interested in seeing how LZ4 foreground compression with Zstd-19 background compression works with Bcachefs in the future whenever that becomes possible. I hope OpenZFS picks up foreground/background compression. That's really kickass feature.

[skeevy420]

... so the bca chefs have more time for the cooking.

My ignorant ass had to read that three times to get the joke. Dafuq is a B.C.A. chef?

[intelfx]

We'll see in the hours ahead if there is any unexpected surprises prior to Linux 6.5-rc1 being released, but it's looking more than likely that Bcachefs will not be accepted this cycle.

Well duh, of course it won’t. There are outstanding issues and at least two NAKs from high-profile maintainers.

[fitzie]

I would like to see a summary. Reading LKML is difficult if you aren't used to it!

Can anyone summarize the discussion? It seems Kent had some differences with a few developers.

There's some people complaining sbout the non-bcachefs changes, as usual.

I would like Bcachefs getting mainlined and more talented developers get involved into this interesting filesystem.

I've read through it, and I find this to be the most positive direction forward:

https://lore.kernel.org/lkml/20230706164055.GA2306489@perftesting/

There is clearly personality conflicts, but they really go to the heart of the review issue: Kent is not just patching outside bcachefs, he's struggling to get a plan of action, either compromise the design of bcachefs, or keep some of these improvements inside bcachefs. There seemed to be a good technical path forward, but what I think what is tough for Kent is that these outside of bcachefs conversations weren't resolved, and several ended up in acrimony. There were a lot of people sticking up for Kent, sympathizing what it takes to maintain an out of upstream filesystem and acknoledging he's been a long term kernel maintainer and there's limited risk that he's not going to support the filesystem.

Ultimately, I think it will go in, probably next cycle, with Linus sweeping in. But Kent seems to be entrenched with is hair trigger defensiveness and a commitment to mutual hostility, that's not good. if bcachefs cannot attract the wandering gunslingers like Christoph, then not only will bcachefs suffer, but those are developers who really help get changes into vfs/mm/iomap layers that Kent wants to improve.

That being said, I should repeat that Kent seems to work productively with various kernel developers. I have faith he will get it in. I've been a patreon supporter of bcachefs for many years, and I'm looking forward to it taking this next step.

[skeevy420]

I've read through it, and I find this to be the most positive direction forward:

https://lore.kernel.org/lkml/20230706164055.GA2306489@perftesting/

Thanks, and, damn, he went there:

2) We already have recent examples of merge and disappear. Yes of course you've
been around for a long time, you aren't the NTFS developers. But as you point
out it's 90k of code. When btrfs was merged there were 3 large contributors,
Chris, myself, and Yanzheng. If Chris got hit by a bus we could still drive the
project forward. Can the same be said for bachefs? I know others have chimed
in and done some stuff, but as it's been stated elsewhere it would be good to
have somebody else in the MAINTAINERS file with you.

[fitzie]

Thanks, and, damn, he went there:

An xfs/ext4 developer responded to that line:

The same can't even be said about ext4 or xfs -- if Ted, Dave, or I
disappeared tomorrow, I predict there would be huge problems within a
month or two.

I'm of two minds here -- I want to say that bcachefs should get merged
because wasting Kent's mind on rebasing out of tree patchsets is totally
stupid and I think I've worked over his QA/CI system enough to trust
that bcachefs isn't a giant nightmare codebase.

OTOH there's so many layers of tiny helper functions and macros that I
have a really hard time making sense of all those pre-bcachefs changes.
That's why I haven't weighed in. Given all the weird problems we've had
recently with new code colliding badly with under-documented optimized
core code, I'm fearful of touching anything.

From https://lore.kernel.org/lkml/2023070...ogsfrogsfrogs/