Bcachefs status update, current work
lkml.org
lkml.org
Edit: Oh, it looks like it does have a corporate sponsor now!
It would presumably match the described focus in the LKML update:
> My current priority is reflink - as that will be highly useful to the company that's funding bcachefs development
… as making copies of large audio / video files is likely a common operation in post-production.
GNU/Linux desperately need a modern storage solution, well ANY OS I know of except DragonflyBSD (Hammer) do need it.
Though it's not convenient to use for normal desktop systems (something like Partition Manager and Gparted don't support it).
If that's up to date:
* https://btrfs.wiki.kernel.org/index.php/Status
That said, you can support Bcachefs development here: https://www.patreon.com/bcachefs
It looks very promising, and can get better than Btrfs.
I encountered enough permanent BtrFS file system corruptions when the power would suddenly go out after a storm... which I thought should have been impossible with copy-on-write file systems that use extents... apparently not.
BCacheFS is looking far more stable, even this early in its development.
"Basically, there's a new btree transaction context widget for allocating btree iterators out of, and queuing up updates to be done at transaction commit - so that different code paths (e.g. inode create, dirent create, xattr create) can be used together without having to manually write code to keep track of all the iterators that need to be used and kept locked, etc. I think it's pretty neat how clean it turned out."
BCacheFS's development is slow, but that's because stability is the ultimate goal. Don't rush to make everything work, but gradually crank out stable code that's actually reliable.
Kent almost single-handedly developed BCache, but eventually, other kernel maintainers took over from him. BCache is basically stable now.
Kent's plan for BCache was for it to be the basis for BCacheFS from the very beginning, it seems. So, while BCache does what it's good at, it is also architectured to make developing BCacheFS easier.
Basically, Kent has been building an entire filesystem almost single-handedly, and has been doing so much better than BtrFS has been.
Kent has a corporate sponser now, thankfully, so he can a bit more easily afford to spend more time on it.
His Patreon donations seem bare-minimum, though, for the task. Enough-ish, but not ideal.
That said...I'd be curious what data you're storing on that btrfs raid and how mission-critical you consider it to be. Is this a homelab/testing NAS, or is this where you're storing the backups of your wedding photos?
From https://btrfs.wiki.kernel.org/index.php/Status#RAID1.2C_RAID... :
> RAID1, RAID10
> The simple redundancy RAID levels utilize different mirrors in a way that does not achieve the maximum performance. The logic can be improved so the reads will spread over the mirrors evenly or based on device congestion.
Which reads to me like a sugar-coated way of saying "if you have 2 mirrored drives, it'll try really hard to read only from the first one, rather than splitting the load evenly across the two".
> RAID56
> Some fixes went to 4.12, namely scrub and auto-repair fixes. Feature marked as mostly OK for now.
I personally don't trust a NAS filesystem that claims to be "mostly OK for now" for RAID 5/6 and throws away the biggest performance benefit of RAID10.
My own home NAS runs ZFS, and has for 5+ years, under various iterations of FreeBSD and Linux. I'm quite happy with it, but I'm also looking forward to bcachefs, once it hits the mainline kernel. Especially as the root-on-bcachefs story matures, since as happy as I am with ZFS on Linux, the impedance mismatch between ZFS and Linux bootloaders continues to make ZFS root not impossible, but more complicated than it ideally should be.