Why would Btrfs have a big(ger) future than Bcachefs when the latter seems to have the same functionality and less 'historical baggage'†?
I remember when Btrfs was initially released (I was doing Solaris sysadmining, and it was billed as "ZFS for Linux"), and yet here we are all these years later and it still seems to be 'meh'.
By the time future-bcachefs has feature parity with present-btrfs, who knows what more will be in future-btrfs?
For your specific example, bcachefs's erasure coding is very experimental and currently pretty much unusable, while btrfs is actively working towards fixing the raid56 write hole with the recent addition of the raid-stripe-tree. By the time bcachefs has a trustworthy parity profile, btrfs's may be just as good.
My specific example says that the bcachefs are "actively working towards fixing the raid56 write hole" as well—or rather, their way of doing things doesn't have one in the first place.
> bcachefs are "actively working towards fixing the raid56 write hole" as well
Yep, that's my point. Neither btrfs nor bcachefs have a write-hole-less parity raid profile implementation yet, and both are working towards one. We don't know if one will be finished and battle tested significantly before the other, or if one will prove to be more performant or reliable. Just have to wait and see.
I remember when Btrfs was initially released (I was doing Solaris sysadmining, and it was billed as "ZFS for Linux"), and yet here we are all these years later and it still seems to be 'meh'.
† E.g., RAID5+ that's less likely to eat data:
* https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
* https://bcachefs.org/ErasureCoding/ / https://github.com/koverstreet/bcachefs/issues/657