Benchmarks Of The Btrfs Space Cache Option

When the Dbench client count was set to 12, the benefits of using space_cache were much smaller but still measurable. There was also a small improvement tacked onto the compress results when using both mount options.

Using the compress mount option more than tripled the write performance with FS-Mark while the space_cache option only enhanced the Btrfs file-system performance by a tiny bit.

With 64MB random writes using 32 threads on Threaded I/O Tester, the space_cache option provided for some improvements while again the compress option resulted in a much more dramatic speed-up.

Lastly, with AO-Stress, the space_cache mount option was worthwhile but not as comparatively great as using the compress option.

Overall, the space_cache option when using the Btrfs file-system on Linux 2.6.37+ kernels will result in improved performance. However, in two of the tests there were odd performance regressions when pairing the space_cache and compress mount options. One of the only other drawbacks to using space_cache on Btrfs is that when the file-system is mounted with this option, the file-system can no longer be mounted later on by any pre-2.6.37 kernels due to the disk format changing. The compress mount option continues to work very well for speeding up the Btrfs performance in nearly every test. Going forward though the space_cache option is great and eventually will hopefully be used by default.

Discuss this article in our forums, IRC channel, or email the author. You can also follow our content via RSS and on social networks like Facebook, Identi.ca, and Twitter (@Phoronix and @MichaelLarabel). Subscribe to Phoronix Premium to view our content without advertisements, view entire articles on a single page, and experience other benefits.