Bcachefs Boasts Hefty Optimization For Linux 6.8: 4k MT Random Writes Jump ~30%

[phoronix]

Phoronix: Bcachefs Boasts Hefty Optimization For Linux 6.8: 4k MT Random Writes Jump ~30%

Following the Bcachefs file-system having finally been upstreamed in the Linux 6.7 kernel, with the Linux 6.8 merge window now ticking the file-system's lead developer Kent Overstreet has submitted a set of feature additions and performance optimizations to this copy-on-write (CoW) file-system...

https://www.phoronix.com/news/Bcachefs-Updates-Linux-6.8

[hajj_3]

that's a lot of improvements in such a small amount of time. I wonder if the number of people contributing has increased a lot.

[spicfoo]

that's a lot of improvements in such a small amount of time. I wonder if the number of people contributing has increased a lot.

It hasn't. The vast majority of changes are still from Kent Overstreet. Brian Foster from Red Hat IIRC has been added as a co-maintainer but a lot of changes were staged but not merged earlier because the focus was on getting a smaller subset merged first. This should taper off in a few cycles.

[anarki2]

that's a lot of improvements in such a small amount of time. I wonder if the number of people contributing has increased a lot.

My thoughts exactly, 210 commits from Kent alone, that's crazy for such a short period of time.

In any case, 7% of commits already come from other people, not too shabby imo, especially given that allegedly a lot of other commits are still being held off.

[jbean]

I really want scrub, better RAID device monitoring after a drive has failed while the array is mounted, and some way of mounting subvolumes/snapshots like with btrfs. Basically, I want some feature parity with Btrfs so I can move on from it, as it otherwise looks real promising.
Bonus if bcachefs can get proper rebalance working. Btrfs has this (albeit very buggy) already. It's a hard thing to pull off when dealing with different size devices but I'm hopeful it comes together. And then who can forget erasure coding
But scrub, raid monitoring and better subv mounting/snapshot rollback is kind of critical to me in order to switch. So looking forwarding to seeing which kernels start seeing patches to improve that.

[AlanTuring69]

My thoughts exactly, 210 commits from Kent alone, that's crazy for such a short period of time.

In any case, 7% of commits already come from other people, not too shabby imo, especially given that allegedly a lot of other commits are still being held off.

As another comment mentioned, I think the code has mostly already been written but going through the process of getting the mainline kernel up-to-date with the local bcachefs state, which has a bit of history. The kernel is very particular about commit history so reconstructing it is a bit of a process.

Not to take anything away from it, of course. I hope to see the work continue and to have a real competitor to ZFS, which Btrfs does not attempt to be.

[mdedetrich]

Its funny to see the amount of dribble that was happening some months ago with all of the disproportionate negative criticism of bcachefs and why it "wasn't for Linux" and now that it has been merged to Linux, things are proceeding as normal (arguably better than normal now, these improvements are quite significant).

While it is true that Kent is a bit of a bus factor, at the same time this is not that unusual for Linux components even for filesystems (I mean look at the state of XFS). The s**tshow regarding all of the personal problems turned out to be people having ego issues + mailing lists being a terrible tool for modern software project management.

At the end of the day while its legitimate to bring forward concerns about maintainability, its not fair to use this as an argument to stonewall the inclusion of bcachefs so I am really glad that that it all ended up getting through. To add onto this, I would even say its not a ludicrous proposition if bcachefs in a few years ends up becoming serious competition to btrfs/zfs, at least based on the current progress thats been happening (and the fact that Kent spent a lot of effort trying to, as much as possible, perfect the design of the fs before even trying to merge it upstream unlike btrfs).

[Pirunvirsi]

Is the cuck brigade still mewling and pearl clutching that this guy isnt PC enough

Given how they have better things to do than making up people in their minds to be angry at in reference to events that never happened, I’d say no.

[fitzie]

Is the cuck brigade still mewling and pearl clutching that this guy isnt PC enough

kent picking fights over nothing is more of a concern of how bcachefs will get along. there's a bunch of stuff that naturally migrates from individual filesystem to core layers of the kernel and bcachefs will become an island if that doesn't improve. iomap is an example of this, came from xfs, used to replace buffer heads, now btrfs uses it. kent doesn't use it in bcachefs for technical reasons, but the conversation to improve iomap went nowhere fast due to him bickering. bcachefs sixlocks is another area where bcachefs is its own island. this will prevent developers getting on board and I suspect lead to technical issues. kent started attacking the kernel lock developers so they basically don't even review what's in bcachefs.

[mdedetrich]

kent picking fights over nothing is more of a concern of how bcachefs will get along. there's a bunch of stuff that naturally migrates from individual filesystem to core layers of the kernel and bcachefs will become an island if that doesn't improve. iomap is an example of this, came from xfs, used to replace buffer heads, now btrfs uses it. kent doesn't use it in bcachefs for technical reasons, but the conversation to improve iomap went nowhere fast due to him bickering. bcachefs sixlocks is another area where bcachefs is its own island. this will prevent developers getting on board and I suspect lead to technical issues. kent started attacking the kernel lock developers so they basically don't even review what's in bcachefs.

The number of fights that has broken out since the code is merged?

Big fat zero

That entire episode was one big drama theatre, let it go.