Btrfs Performance From Linux 6.12 To Linux 7.0 Shows Regressions
For the MariaDB SQL database server with a mix of reads and writes, the Btrfs performance was trailing behind EXT4 and XFS after it was overtaken in Linux 6.13.As noted in the prior article, in Linux 6.13 is the point at which AMD EPYC 9005 Turin servers shifted over to the AMD P-State driver by default in place of the generic CPUFreq driver. For database servers, video encoding, and other workloads the shift to amd_pstate driver usage made a impact on performance but less so in the case of Btrfs.
The MariaDB write performance on Btrfs had improved in Linux 6.13 and 6.14 before falling back to its 6.12 levels on Linux 6.15 and later.
With the mariadb-slap benchmark, the performance was stable on Linux 6.13 and later across all tested file-systems.
While there was a nice speed-up for EXT4 with PostgreSQL on Linux 6.16, the Btrfs performance with PostgreSQL at the file-system defaults was much more muted.
Going into this testing I was expecting to see some nice Btrfs performance gains over the past year and a half of Linux kernel releases. Surprisingly, there were regressions -- the Tigerbeetle issue as well as FIO random writes, both on Linux 6.15+ standing out and playing a big role in the geo mean letdown -- and a much more reserved look compared to some of the improvements found with EXT4 over this same time-frame. Of course, beyond just raw file-system performance are other important factors to consider in choosing a file-system like its feature set, data security/safety, and more.
If you enjoyed this article consider joining Phoronix Premium to view this site ad-free, multi-page articles on a single page, and other benefits. PayPal or Stripe tips are also graciously accepted. Thanks for your support.