Bcachefs status update, current work(lkml.org)
lkml.org
Bcachefs status update, current work
https://lkml.org/lkml/2018/12/2/46
19 comments
I'm a big fan of Bcachefs, but why hasn't it attracted any corporate sponsorship? Is ZFS/XFS/Btrfs "good enough" or is everyone burnt out on "next-gen" filesystems?
Edit: Oh, it looks like it does have a corporate sponsor now!
Edit: Oh, it looks like it does have a corporate sponsor now!
Who is backing it?
It could be elements.tv based on this article[0].
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.
[0]: https://www.patreon.com/posts/whats-cooking-15861769
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.
[0]: https://www.patreon.com/posts/whats-cooking-15861769
elements.tv gets my vote, then! :)
In the mean time I'm a happy nilfs2 user (not so happy for the cleaner performance but in the end it works) down from the root. A logfs is really nice against accidental overwrite/delection and coupled with LUKS+LVM while far from zfs comfort and perhaps future bcachefs it can work with enough flexibility (nilfs2 can resize both in grow and shrink direction live and IME issueless).
GNU/Linux desperately need a modern storage solution, well ANY OS I know of except DragonflyBSD (Hammer) do need it.
GNU/Linux desperately need a modern storage solution, well ANY OS I know of except DragonflyBSD (Hammer) do need it.
OpenZFS is available, if you need something right now.
Though it's not convenient to use for normal desktop systems (something like Partition Manager and Gparted don't support it).
Though it's not convenient to use for normal desktop systems (something like Partition Manager and Gparted don't support it).
I have used it both FreeBSD port and LLNL port but for now on GNU/Linux IMO it's better LUKS+LVM+nilfs2 for stability and performance...
So if anyone can help: I've got a nice BTRFS raid nas at home, and I'm wondering if I should switch the bcachefs?
If you're happy with your current btrfs setup, no need to switch.
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.
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.
Btrfs is quite ahead features wise.
If that's up to date:
* https://bcachefs.org/Todo/
* https://bcachefs.org
* 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.
If that's up to date:
* https://bcachefs.org/Todo/
* https://bcachefs.org
* 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.
The bcachefs web site is definitely not up to date, although I still wouldn't recommend it for normal users before it goes upstream :)
Some of us are quite happy to test it. ;)
BtrFS is ahead, sure, but the code is nasty garbage.
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.
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.
It seems like bcachefs has the infrastructure that is lacking for btrfs to become robust without superhuman intelligence and / or working memory. From the post:
"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."
"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."
Indeed.
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.
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.
No, the disk format is not guaranteed stable yet. Rushing to stabilize the disk format for Btrfs was a big mistake. Bcachefs is playing it safe! Wait for it to be mainlined.
https://www.patreon.com/bcachefs