I've noticed that while there's a great CSI driver for ZFS and previous container solutions like LXD and Docker have great Btrfs support, the mainstream CSI drivers hardly use Btrfs's atomic snapshots. Most of them only deal with block-level snapshots, which aren't always consistent. I wonder why taking a Btrfs snapshot before making a block-level snapshot isn't more common. Is it just that Btrfs isn't widely adopted in environments where CSI drivers typically operate? Seems like it might be a chicken-and-egg situation since many of its unique advantages aren't utilized because of this lack of adoption.
5 Answers
A lot of people stick to more traditional filesystems like ext3/4 and XFS. Btrfs just isn't common enough in production workloads for Kubernetes operations. From my experience over the past 13 years, I've never seen it being used in the workplaces I've been at.
Exactly! Using a block-level backup on a Btrfs volume without considering that atomicity can lead to data loss, which is a huge risk.
Many enterprises stick to solutions like Ceph or ZFS instead. They’re also often using cloud storage rather than relying on local filesystems. For smaller systems, ext4 and XFS still seem to be the go-to choices.
True, although storage snapshots are instant, so they have their own benefits. I wonder why more block-level CSIs support Btrfs without utilizing its snapshot capabilities.
I think it's just not a priority for many developers working on these CSIs.
I personally find Btrfs has great features like snapshots but it's still viewed as less stable compared to ZFS, which is a shame since it can perform some tasks better.
It depends on how you use it. If you stick to the basics and ignore the parts the docs advise against, it can work pretty well.
I feel Btrfs can perform okay for read-heavy workloads but struggles with write-heavy applications.
I’ve always viewed Btrfs as more of a "toy project" rather than something you’d rely on for serious work. It just doesn’t seem ready for prime time.
It definitely depends on how it's implemented. For basic uses, it's fine, but it lags behind for performance-intensive tasks.
Btrfs might be less resource-intensive than ZFS, but maybe it matured at the wrong time when everyone started moving to distributed filesystems.
Btrfs has a stigma about it not being production-ready, which affects its acceptance. Unfortunately, any incidents caused by Btrfs tend to stick in people's minds, making them hesitant to adopt it even for non-critical applications.
Yep, I’ve seen outages caused by it in various work setups. It’s been banned completely in my environment because of that.
Right? I think until those perceptions change, it will struggle to gain traction.
Totally agree! Plus, Btrfs is complex and seems less maintained compared to the others. Reliability should be a top priority in production environments.