Linux Don’t Need No Stinkin’ ZFS: BTRFS Intro & Benchmarks

Benchmark Observations

There are a few observations from the benchmark results one can make. Obviously these observations are the author’s so any different interpretations are welcome.

• The default options for btrfs produce very good performance relative to ext4 and much better performance than ext3.
• Turning off data check summing and copy-on-write results in slightly better performance. In the author’s opinion losing the added protection of data check summing and copy-on-write are not worth the minimal addition in performance.
• When compression was turned on the performance increased by a large amount. The write and rewrite performance almost doubles and the read and reread performance increases by about 30%.

• The reason for this is that iozone uses zeros in it’s testing. Consequently, the compression feature is able to really compress the data stream producing results that doesn’t reflect the actual performance.
• In essence you are CPU bound and not disk bound (the performance is driven by the ability of the CPU in compressing the data stream.
  
  
• Using only a single copy (i.e. “-m single” of the metadata does not increase performance.
• When two disks are used, the general write and rewrite performance increases by about 50% and the write and rewrite performance increase by about 30%. What is interesting is that the single disk write and rewrite performance with compression turned on is faster than the two disk performance. Moreover, the read and reread performance of the single disk with compression turned on is about the same as for two disks.

• When compression is used in combination with copy-on-write and no data check summing, the performance on writes and rewrites decreases dramatically – by about 30%. However, the read and reread performance has not been impacted much. This shows that this particular benchmark is more driven by CPU performance than disk performance (it is an old single core CPU).

The observations may or may not be applicable to your situation because they are based on the iozone benchmark and that may not reflect your usage pattern. However, for a file system that is in development, btrfs already has great performance. More over, when compression is turned on for a single disk, the performance on iozone is quite remarkable.

Summary

The development and progress of Linux has been quite remarkable. However, one of the aspects that people have been clamoring for is a better file system. People have been asking for one that has enterprise features and that compete with file systems such as ZFS. Btrfs is the answer to these needs. It has a feature set unlike any other and is under very heavy development with very rapid progress. Btrfs was merged into the mainline kernel as of 2.6.29 but is still considered experimental. Not all of the features planned for btrfs have been implemented but the current feature set (version 0.18) has a very large number of useful features.

Even though btrfs is still experimental it was used in a CentOS 5.3 system with a 2.6.30-rc1 kernel and iozone was run with various options. The base performance of btrfs is about the same as ext4 on both reads and writes. As mentioned in the observations in some of the cases, the performance is driven by disk performance and sometimes it is driven by CPU performance (in the case of using compression). You also have to be very careful of the details of the benchmark because as was pointed out, the iozone benchmark uses blocks or zeros that a compression algorithm can easily compress at the expense of CPU cycles.

If you’ve read this article this far then you are probably a Linux fan or have an interest in Linux. One good way to contribute to Linux is to test btrfs and report any problems (or successes) to the btrfs mailing list.