I haven’t used it yet personally, but I would bet as soon as Debian/Ubuntu LTS/CentOS/openSuse/other stable Linux distros get kernels new enough to it will be not just a btrfs killer, but a ZFS killer too.
The tiered write and read layers and SMR support put ZFS caching to shame.
Nobody uses SMR for live data anyway unless it’s in very particular circumstances.
Bcachefs is still at least a couple of years away from serious use. But sure, if it’s available and you have a good backup strategy you can use it today.
As for “years away” I agree. As my first post said people should wait till you can use bcachefs in the stable distros. Debian isn’t getting kernel 6.7 any time soon 😆. So years away is right in any case.
I think bcachefs addresses the reason why people don’t use SMR HDDs. (Aka changes resulting in cascading writes)
You could have a data pool with the following tiers.
Tier 1: SSDs
Tier 2: HDDs
Tier 3: SMR HDDs
With bcachefs you would only ever write to your tier 1 storage. In the background, as able, bcachefs would offload the data from the faster lower tiers to the slower higher tiers based on frequency of data access.
You would only ever read from the SMR HDDs and would never write to them. They act as a sort of async backing to your data.
Personally I would love a data pool with a few SSDs, backed by a few HDDs, backed by many SMR HDDs. You would save so much money just with good architecting.
Bcachefs should be a ZFS killer. All the features of ZFS with storage tiers being a superior version of ZFS’s L2arc with none of the DKIM kernel license incompatibility nonsense.
Damn, I didn’t think to include SMR drives when it comes to bcachefs. Your whole comment made me appreciate the whole concept under a whole new light actually, thanks!
I haven’t used it yet personally, but I would bet as soon as Debian/Ubuntu LTS/CentOS/openSuse/other stable Linux distros get kernels new enough to it will be not just a btrfs killer, but a ZFS killer too.
The tiered write and read layers and SMR support put ZFS caching to shame.
Nobody uses SMR for live data anyway unless it’s in very particular circumstances.
Bcachefs is still at least a couple of years away from serious use. But sure, if it’s available and you have a good backup strategy you can use it today.
As for “years away” I agree. As my first post said people should wait till you can use bcachefs in the stable distros. Debian isn’t getting kernel 6.7 any time soon 😆. So years away is right in any case.
I think bcachefs addresses the reason why people don’t use SMR HDDs. (Aka changes resulting in cascading writes)
You could have a data pool with the following tiers.
Tier 1: SSDs
Tier 2: HDDs
Tier 3: SMR HDDs
With bcachefs you would only ever write to your tier 1 storage. In the background, as able, bcachefs would offload the data from the faster lower tiers to the slower higher tiers based on frequency of data access.
You would only ever read from the SMR HDDs and would never write to them. They act as a sort of async backing to your data.
Personally I would love a data pool with a few SSDs, backed by a few HDDs, backed by many SMR HDDs. You would save so much money just with good architecting.
Bcachefs should be a ZFS killer. All the features of ZFS with storage tiers being a superior version of ZFS’s L2arc with none of the DKIM kernel license incompatibility nonsense.
Damn, I didn’t think to include SMR drives when it comes to bcachefs. Your whole comment made me appreciate the whole concept under a whole new light actually, thanks!