While I'm obviously interested in benchmarks and performance (I'm author of the blog post referenced here), I'm perfectly OK with sacrificing some of the perfor

While I'm obviously interested in benchmarks and performance (I'm author of the blog post referenced here), I'm perfectly OK with sacrificing some of the performance in exchange for advanced features provided by the filesystem. For example built-in snapshotting, additional data integrity guarantees thanks to checksums (e.g. resiliency to torn pages) etc. Because you either can't get that with the traditional filesystems or it'll come at a cost (e.g. LVM adds complexity and has impact on performance). What I'm not quite OK with is getting very unstable performance - with OLTP workloads you really want smooth behavior, not the jitter or random issues you get with BTRFS. Especially when the other COW filesystems like ZFS perform so much more sensibly. I don't think comparing F2FS and BTRFS is entirely fair, though. Those are filesystems with very different goals, F2FS is mostly designed to work with single SSD devices (so no RAID-like stuff like BTRFS) and lacks many of the advanced features (you can't even do snapshots). Also, it was not my intention to say that BTRFS is somehow conceptually wrong and unusable for database workloads. But the current state is not really something I'd recommend for OLTP in production - that's what the rant is essentially about.