Bcachefs Repair Code Reaching Complete & Robust Recovery

[phoronix]

Phoronix: Bcachefs Repair Code Reaching Complete & Robust Recovery

Just two days after a Linux 6.9 pull request was submitted for Bcachefs to better cope with "extreme file-system damage", another pull request for this current cycle was submitted that aims to improve the recovery capabilities of this newer copy-on-write open-source file-system...

https://www.phoronix.com/news/Bcachefs-Repair-Looking-Good

[TiCPU]

It did blow my mind when I was informed this person had metadata replica set to 1. Always surprised too see all this fsck code is part of the kernel module itself.

[intelfx]

I really doubt that it's going to be accepted for an -rc3...

Noble intentions, yes, but this is _really_ stretching the process. Wonder what Linus'll say, and I just hope it won't be another one of those century-defining tirades.

[spicfoo]

I really doubt that it's going to be accepted for an -rc3...

Noble intentions, yes, but this is _really_ stretching the process. Wonder what Linus'll say, and I just hope it won't be another one of those century-defining tirades.

It's not a problem because we will have some folks here ready to bring out their pom poms and defend the indefensible no matter what.

[jacob]

I really doubt that it's going to be accepted for an -rc3...

Noble intentions, yes, but this is _really_ stretching the process. Wonder what Linus'll say, and I just hope it won't be another one of those century-defining tirades.

Actually I think perhaps he *should* go into one of those tirades. The process is there for an obvious reason and the bcachefs project already has a history of trying to bend the rules far more than what can be considered reasonable.

[Quackdoc]

yeah I dont see this one getting accepted the last one was already last minute, "new repair code" is not something that should be sent in at RC3.

[NotMine999]

I am wondering if bcachefs was pulled into mainline Linux a bit TOO SOON. I still admire the effort but I appreciate well-tested code more than the bling & glitz of NEW STUFF.

It looks like all of this filesystem & repair code could have benefited from more "soak time" in a "testing" code tree. Users can do absolutely crazy things to code in a "testing" tree that might not regularly appear in a production code tree, and that can be the best time to uncover 'interesting bugs'.

[User29]

I am wondering if bcachefs was pulled into mainline Linux a bit TOO SOON. I still admire the effort but I appreciate well-tested code more than the bling & glitz of NEW STUFF.

It looks like all of this filesystem & repair code could have benefited from more "soak time" in a "testing" code tree. Users can do absolutely crazy things to code in a "testing" tree that might not regularly appear in a production code tree, and that can be the best time to uncover 'interesting bugs'.

TBH I don't know how these bugs come up, but I think adding bcachefs to mainline brought enough attention and people really started to use/test it. So from one point of view yes, you are right, but from another, this was a necessary step to give bcachefs more momentum.

[mdedetrich]

I am wondering if bcachefs was pulled into mainline Linux a bit TOO SOON. I still admire the effort but I appreciate well-tested code more than the bling & glitz of NEW STUFF.

It looks like all of this filesystem & repair code could have benefited from more "soak time" in a "testing" code tree. Users can do absolutely crazy things to code in a "testing" tree that might not regularly appear in a production code tree, and that can be the best time to uncover 'interesting bugs'.

If anything and especially when compared to btrfs, bcachefs got included in the kernel too late not too early. It was developed out of tree for more than half a decade (iirc) where as btrfs was basically shoved into the kernel asap and because of that had a very rushed development.

TBH I don't know how these bugs come up, but I think adding bcachefs to mainline brought enough attention and people really started to use/test it. So from one point of view yes, you are right, but from another, this was a necessary step to give bcachefs more momentum.

Its not a bug, its new code that is designed to repair the filesystem in extremely severe cases of corruption. As in if you deliberate decide to wipe certain parts of the filesystem (or otherwise i.e. hardware failure/severe bitrot) outside of its control and you want to repair that.

[pWe00Iri3e7Z9lHOX2Qx]

I am wondering if bcachefs was pulled into mainline Linux a bit TOO SOON. I still admire the effort but I appreciate well-tested code more than the bling & glitz of NEW STUFF.

It looks like all of this filesystem & repair code could have benefited from more "soak time" in a "testing" code tree. Users can do absolutely crazy things to code in a "testing" tree that might not regularly appear in a production code tree, and that can be the best time to uncover 'interesting bugs'.

It's still marked experimental for a reason. You aren't supposed to be using it for anything you find super important. Distro installers don't offer it. You need to go out of your way to set up a storage pool with it. There are tons of issues that were never going to be found without enough people beating on it every day, and that wasn't going to happen until it was in mainline.