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.
Btrfs evangelists under psychiatric observation for the next 72 hours
Honestly not nearly as painful reading those results as I expected it to be!
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.
F2FS was made primary with removable storage like SD cards and USB thumb drives in mind.
16TB is still a few years away for those, but yes a update to add larger sizes would not be that bad.
Bootable snapshots though that you can use to rollback your system. More than worth the slower speed
Bcachefs just glad to be mentioned