Benchmarks Of The Btrfs Space Cache Option

In early November we delivered benchmarks of EXT4 vs. Btrfs on an early Linux 2.6.37 kernel as our latest round of tests comparing these two leading Linux file-systems. There were some changes in the Linux disk performance with these file-systems using the latest Linux kernel code, but overall it was not too interesting. However, as the Linux 2.6.37 kernel does introduce a new mount option for Btrfs, the space_cache option, we decided to explore its performance in today's article.

When the Btrfs file-system is mounted with the space_cache option, Btrfs is able to store the free space cache on the disk to make the caching of a block group much quicker. Without this support, Btrfs has to scan the entire tree each time looking for space that can be allocated. With today's testing we are comparing the performance of Btrfs on a newly created Btrfs file-system with the Linux 2.6.37 kernel and the latest user-space utilities using the default mount options, using the space_cache mount option, using the compress mount option for Btrfs file compression, and lastly using both the space_cache and compression mount options to benefit from the free space caching and Zlib compression.

The test system was an AMD Opteron 2384, Tyan S2927 motherboard, 4GB of system memory, an OCZ 64GB Agility EX SSD, and an ATI Radeon HD 4870 graphics card. The operating system was Ubuntu 10.10 with the Linux 2.6.37 kernel loaded in using a daily snapshot from 2010-12-22.

Tests powered by the Phoronix Test Suite and OpenBenchmarking.org included SQLite, Apache, Compile Bench, IOzone, Dbench, FS-Mark, Threaded I/O Tester, and AIO-Stress.