The development of this filesystem has been impressive, with ongoing stability improvements. For users seeking an openZFS-like filesystem, but without btrfs’ performance limitations, this option is a good choice. Incorporating it into fedora would be beneficial. Ultimately, it is upto the user to choose but integration of this into fedora make it an another good option for users.
Where do you have this information from?
If bacachefs is enabled by default in the kernel I would expect it to be available for you to test with. But I would suspect that it will be some time before it’s developers will be claiming it production ready.
bcachefs isn’t really OpenZFS like. The feature gap between them is more like a chasm. It is closer to btrfs I guess.
My personal opinion is that bcachefs is not ready for widespread production use yet. In addition to any performance or stability issues one might expect from such a new filesystem, the user-space tools are completely immature.
Lookinto my post i have Added the source and this was a known to be slow i can share other sources other organisations those have better skillset and equipment to do such test.
This is not switching to a new fs rather provide a option which can be used.
That benchmark is on an unreleased kernel.
That benchmark does not compare file system features only raw speed.
It does not for example take into account corruption detection.
https://www.phoronix.com/review/linux-611-filesystems/
With the new kernel performance of Bcachefs improved.
Should this be moved to the Water Cooler…?
1 Like
I guess the bcachefs might not be ready yet:
You did not understand why it was due to he was pushing a hugh chnageset in a far rc which is not right.and seems like he maybe a very good developer but a good collaborator which lead to this.
As I read the situation Linus was indeed upset about the large changeset, but his comments are about regretting merging any of the bcachefs code in earler kernels.
I’m under the vague impression that Btrfs does CoW as a star-feature and the concept of that implies it’s slower than non-CoW (ext4, XFS). Not quite sure if that’s a performance limitation, but iirc there was no point to using Btrfs without CoW. I also kind-of have concerns with CoW on SSDs (sounds odd to copy again on limited-life SSD cells as a data recovery benefit).
I tried ZFS on FreeBSD and found performance great, but didn’t hear CoW described as a feature for it. I’m mainly interested in performance.
Unless bcachefs is something I can use plainly on a root partition from Anaconda drop-down, I’m not exactly in a rush to stop using tried-and-true ext4/XFS/F2FS 
1 Like
And how did you come to a such conclusion 
?
Quoting Linus:
This is too big, it touches non-bcachefs stuff, and it’s not even remotely some kind of regression.
At some point “fix something” just turns into development, and this is that point.
Nobody sane uses bcachefs and expects it to be stable, so every single user is an experimental site.
I read above as this:
- Filesystem developer hijacks the process
bcachefsis not stable yet
The former for me is the red flag about the attitude and could lead to bad code quality questioning filesystem readiness “for general use”.
The latter makes it not ready “for general use” in my understanding despite all the glory the filesystem gets in isolated/lab benchmarks.
zfs definitely uses CoW.
1 Like
Thanks I hate it now
Nah I guess I’ll learn more about how CoW works, but seeing it perform pretty good makes me a little more-receptive of the concept!
For use cases where CoW is a poor choice you can set attributes to turn CoW off with btrfs. An example where CoW is bad is databases.