I started using cachyos only several months ago, and had been a happy user with bcachefs partitions.
But right now it looks like it will be 100% kicked of out mainline kernel and will be packaged as dkms module later. Does cachyos have plans on providing such module and/or compiled kernel, alike -zfs variants?
I don’t know anything about cachyOS interesting in this, but I know that is very easy to use zfs on cacyos, just install Linux-cachyos-zfs (or your kernel of choice) and zfs-utils and you good to go, zfs is a superior filesystem and volym manager, I can understand if you already have bcachefs on your system but I highly recommend to switch to zfs.
he said hes happy with bcachefs as many other ncluding me to. ZFS is way slower … and not really better in saving Data
I hope bcachefs stays in kernel and linus pull his head out his butt
Bcachefs’s developer, Kent Overstreet, has repeatedly violated the Linux Code of Conduct, repeatedly complained when his changes weren’t immediately pushed into the repo, and repeatedly objected to people daring to question his quality of code. He’s the one who needs to get his head out of his ass.
I guess, we’ll need the module now to keep bcachefs up to date
I would be interested in an official statement from CachyOS (although every distro is going to have to figure it out lol) on how they’re going to handle this. Whether they’ll add Bcachefs updates directly to the kernel themselves, dkms, etc etc. I’m setting up a new system soon, and I would like to use Bcachefs. I think it makes sense that they’re going to see whether arch is going to officially package it, in what manner they’ll do so, etc etc.
Well at very least I hope cachyos members will release a migration guide. I am not sure how to migrate from current kernel to a new kernel + DKMS module safely for a filesystem, in case they don’t plan to provide the kernel with included module
I know I don’t will get friends by this, but if you used bcachefs for anything else than a testing installation without any important data, then you should get your head checked:
- bcachefs is still marked as experimental and has a lot bugs. Kent points with his finger at the bugs of other filesystems, but he is in this situation because of his behaviour and the bugs he tried to fix in unconventional ways.
- it’s slow , see the phoronix benchmark https://www.phoronix.com/review/linux-615-filesystems
- Kent stops developing things when he loses interrest, like bcache, that was his main project before bcachefs
- bcachefs is an one man show with only one developer. If Kent gets into an accident and isn’t able to code for a half year, then nobody will fix bugs and security holes in that time.
Kent probably will create a DKMS and I don’t see why Arch wouldn’t distribute it. If he doesn’t, then BCacheFs will be at least available in 6.17 (and maybe even longer), so you have at least like 3 months to save your data and reinstall with another filesystem.
And yet bcachefs has stabalized way faster than btrfs has. btrfs has taken over a decade to get rid of the majority of the bugs, and some still exist (i.e. the RAID5 write hole, there is a new on disk format to fix this but that new format has to be tested)
Maybe you should actually read the thread to figure out why. The main issue is the default block size for bcachefs was off the mark and thats what was used in those tests. Is it bcachefs fault? Yes. Is it anything fundamental with the design of bcachefs? No
You can say the same thing for more than a half of the modules in the Linux kernel. bcache isn’t getting that much work on it because it has a small scope (its a caching submodule for block devices) and its basically been stable.
tl;dr Is that there isn’t really any more work that is needed on it, its basically done. As are a lot of other Linux modules/subsystems