Linux Pulls In Two Serious Bug Fixes For Bcachefs

[phoronix]

Phoronix: Linux Pulls In Two Serious Bug Fixes For Bcachefs

Overnight the latest fixes to the Linux 6.8 kernel were merged including two that are "serious" and will be back-ported to the existing stable Linux 6.7 kernel as well...

https://www.phoronix.com/news/Bcachefs-Two-Serious-Fixes

[geerge]

I'm going bcachefs on root end of this month. Crack on with the bug fixes.

[fitzie]

I hope kent didn't scare away bug reporters with comments like this:

from https://lore.kernel.org/linux-bcache...zyshcyvyfun3i7 @y6q267iebdgg/

So can we please find a way to do this that's more respectful of my time and yours, and not the most inefficient way possible?

[varikonniemi]

The race condition seems a bit esoteric to be classified serious, IMO. To trigger it you would need to call close as soon as the fd becomes available to userspace, and have the kernel thread be scheduled out so that your userspace close gets executed before the accounting on the kernel thread has time to execute.

The subvolume deletion issue on the other hand seemed to be a real issue that happened in the wild that put the filesystem in a degraded state preventing automatic mount.

[F.Ultra]

I hope kent didn't scare away bug reporters with comments like this:

from https://lore.kernel.org/linux-bcache...zyshcyvyfun3i7 @y6q267iebdgg/

there is a lot of context missing from your quote. The full message from Kent is:

Most of them weren't real bugs, just places where I tweaked the code to
please the static analyzer; I believe the number of actual bugs was more
like 3-4.

And I also asked about getting it running locally, after spending
several days fighting with llvm incompatibilities; it turned out the
default build configuration was shipping with that option on when you
weren't even using it, as I recall, and the database stuff isn't
remotely documented - so it seems you want to be the only person who can
run your tool. Oof.

So can we please find a way to do this that's more respectful of my time
and yours, and not the most inefficient way possible?

And the last post in the thread currency also contains this:

On Thu, Feb 01, 2024 at 01:00:10PM +0300, Dan Carpenter wrote:
> This email thread has gone very badly and I'm definitely 50% responsible
> for that. I apologize.

No need to apologize; conflict between ideas is inevitable, and it's not
a bad thing provided we can keep the discussion focused on the
essentials.

[fallingcats]

there is a lot of context missing from your quote. The full message from Kent is:


And the last post in the thread currency also contains this:

Seems like some people on this forum want to make a mountain out of es a molehill. So business as usual I then, I suppose.

[Quackdoc]

But because this is a tool that only you can effectively run, you're
forcing me into your workflow, and that is where I have to put my foot
down.

Interesting, seems like it would be better for this tool to be more standardized and shared? Not sure what this tool is myself.

[varikonniemi]

Interesting, seems like it would be better for this tool to be more standardized and shared? Not sure what this tool is myself.

just some static analyzer the author wants to monopolize so he can feel important being the one that reports "bugs" it found. Which are more correctly described as theoretical nitpicking with no real world consequences most of the time. Hence the inflamed tone of koverstreet

[pWe00Iri3e7Z9lHOX2Qx]

My initial experiment with bcachefs when 6.7 hit Tumbleweed didn't get very far. I created a tiered pool consisting of 4 x 14TB WD Red Pros and 2 x 4TB NVMe SSDs with LZ4 compression and native encryption enabled. Trying to mount it threw an error about unknown command. /sbin/mount.bcachefs was just a symlink to /sbin/bcachefs. When I nuked that it would actually try to mount, but I was getting an error about the required key not being available. The pointer to dmesg only gave "error requesting encryption key: ENOKEY". There's a thread where some others have reported the same issue, and Kent's response was...

The keyring stuff has been a perpetual utter headache.

I've been debating rewriting that stuff to just pass a memfd handle as a
mount option and rip out keyring usage...

alternately - now that we're pretty much always mounting via the mount
helper, perhaps it would be a little bit less fragile if the mount
helper was adding the key to the keyring - that might be worth checking.

https://lore.kernel.org/all/[email protected]/T/#m2e3021f274e8887662422b8afc74c1fae5219e09

It's still marked experimental so this kind of stuff is to be expected. But if just mounting the pool with built in features like encryption on is known to be problematic, I probably have several more major kernel releases before this can replace ZFS for me.

[spicfoo]

just some static analyzer the author wants to monopolize so he can feel important being the one that reports "bugs" it found. Which are more correctly described as theoretical nitpicking with no real world consequences most of the time. Hence the inflamed tone of koverstreet

A) It is an open source tool B) It has been under development for 13 years C) It has found thousands of bugs including dozens in Bcachefs. Many bugs have serious real world consequences. I wouldn't been so keen on downplaying or dismissing it.