Btrfs evangelists under psychiatric observation for the next 72 hours
this post was submitted on 10 May 2025
38 points (95.2% liked)
Linux
7277 readers
282 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Bcachefs just glad to be mentioned
It was never a secret that speed is not Btrfs strongest feature. That was known for years.
I guess I'll look into XFS and see if it's suitable for my use cases (I know almost nothing about it), but this supports my opinion that BTRFS is an easy choice over EXT4 at least.
Edit: No snapshot support in XFS, so I'll stick with BTRFS. My performance requirements are not that high on desktop. If I set up a high-performance server that would be another matter.
I was surprised to learn that F2FS has rather small maximum volume sizes. 16TB with 4K block sizes, 64TB with 16K block sizes. But your whole kernel needs to use 16K pages to use 16K F2FS blocks, which seems like more trouble than it's worth. Either way, it's so non-future-proof I'm not even going to think about it.
Why didn't they benchmark ZFS?
Most likely because it is not a Filesystem that is available as a native, in-tree, Kernel module.
Edit: Yes, there just is no 6.15 Version of the out of tree module for OpenZFS yet
Supported Platforms
- Linux: compatible with 4.18 - 6.14 kernels
Seriously, they're just gonna put the geometric mean of all benchmarks and claim that means anything? Maybe it means something for people who don't care at all about what their most performance-sensitive workloads are.
Just? This is a link to the last page of the benchmarks. The other pages have other workloads on them - quite a lot of DB benchmarks though.