Using Disk Compression With Btrfs To Enhance Performance
Earlier this month we delivered benchmarks comparing the ZFS, EXT4, and Btrfs file-systems from both solid-state drives and hard drives. The EXT4 file-system was the clear winner in terms of the overall disk performance while Btrfs came in second followed by Sun's ZFS in FreeBSD 8.2. It was a surprise that in our most recent testing the EXT4 file-system turned around and did better than the next-generation Btrfs file-system, but it turns out that Btrfs regressed hard in Linux 2.6.35 as to be found in Ubuntu 10.10 and other soon-to-be-released distributions. However, regardless of where Btrfs is performing, its speed can be boosted by enabling its transparent zlib compression support.
In this article we have our Btrfs test results when the zlib compression mount option was enabled for looking at the SSD compression performance added to our EXT4 and Btrfs results from the last article. Again, the test system was a Lenovo ThinkPad W510 with an Intel Core i7 Q 720M CPU, there was 4GB of DDR3 system memory, an OCZ Vertex 2 60GB SSD was used as the disk, and NVIDIA Quadro FX 880M 1GB graphics. The operating system was an Ubuntu 10.10 (x86_64) development snapshot with the Linux 2.6.35 kernel, X.Org Server 1.8.2 RC2, NVIDIA 256.35 display driver, and GCC 4.4.5.
The Phoronix Test Suite tests included Gzip compression, Apache, Compile Bench, IOzone, Dbench, FS-Mark, Flexible I/O Tester, Threaded I/O Tester, PostMark, and Unpack Linux.
Starting off by measuring the time to compress a 2GB file using zlib compression, there was a small but statistically insignificant gain when enabling the zlib-based transparent compression for Btrfs.
There was also no measurable performance gain or loss when enabling the Btrfs compression and running the Apache server benchmark. With the regressed Linux 2.6.35 kernel, EXT4 still was the frontrunner.
Having zlib compression enabled with the "initial create" task in Compile Bench resulted in a 30% drop in performance for Btrfs, which put it at being nearly 70% slower than the common EXT4 file-system.