Btrfs LZO Compression Performance

While the performance of the Btrfs file-system with its default mount options didn't change much with the just-released Linux 2.6.38 kernel as shown by our large HDD and SSD file-system comparison, this new kernel does bring LZO file-system compression support to Btrfs. This Oracle-sponsored file-system has supported Gzip compression for months as a means to boost performance and preserve disk space, but now there's support for using LZO compression. In this article we are looking at the Btrfs performance with its default options and then when using the transparent Zlib and LZO compression.

The LZO compression support for Btrfs was developed by Fujitsu and was added since the LZO algorithm is designed to be much faster than gzlib. With the Linux 2.6.38 kernel and later, zlib or lzo compression can be choosed at mount time by passing the respective compression algorithm to the compress argument. This patch was originally announced back in October (Kernel.org) and then merged into Linux 2.6.38.

We tested the Btrfs file-system at its defaults and then again when freshly formatting the partition and mounting it with the respective compression algorithm. Testing was done on a Lenovo ThinkPad T61 notebook with an Intel Core 2 Duo T9300 CPU, 4GB of DDR3 system memory, NVIDIA Quadro NVS 140M graphics, and a 100GB Hitachi HTS72201 7200RPM SATA HDD. Ubuntu 10.10 was used but the mainline Linux 2.6.38 kernel was used along with dropping in the latest user-space Btrfs tools from Git.

Tests included Compile Bench, IOzone, Dbench, FS-Mark, Threaded I/O Tester, and AIO-Stress. With Apache, PostgreSQL, and our other usual disk tests there was no performance advantage to using the transparent Gzip/LZO compression.