The Linux 2.6.37 Kernel With EXT4 & Btrfs

Written by Michael Larabel in Software on 10 November 2010. Page 3 of 3. 11 Comments

When carrying out eight threads of 64MB random writes, the EXT4 file-system performance improved under the Linux 2.6.37 kernel. It did, however, drop rather dramatically on the same kernel with the Btrfs file-system. In fact, the performance rather nose-dived.

There was not much change in the IOzone 8GB write performance results for EXT4/Btrfs.

...nor was there much change for either file-system on the Linux 2.6.37 kernel with the 8GB read performance.

Overall, the Linux 2.6.37 kernel does not look to drastically change the playing field for the EXT4 / Btrfs file-systems. While we reported recently that Ted Ts'o, the EXT3/EXT4 maintainer, said EXT4 is within striking distance of XFS on very large capacity, multi-threaded setups, for desktop / notebook / netbook users there isn't a whole lot to look at with this latest in-development kernel. In a few areas there are some minor improvements and some losses, but nothing decisive overall.

When it comes to EXT4 on the Linux 2.6.37 kernel there is lazy inode table initialization, which is designed to allow this file-system to run mkfs very quickly. The other major change is changing the I/O submission path so that it uses the block I/O layer directly, which makes block traces smaller and makes EXT4 much more scalable -- such as with the talked about EXT4 vs. XFS comparison. As said by Ted in the 2.6.37 EXT4 pull request, "On the boxacle 'large file create' workload, run with 48 and 192 threads on a 48-core AMD box, ext4 now has a 3x increase in write throughput, and CPU usage has been reduced by a factor of 3-4. Most of this was achieved by reducing spinlock contention on the block queue submission locks." In the Linux 2.6.37 kernel, EXT4 also hooks up to the FITRIM ioctl for run-time discard support of unused blocks.

The Btrfs 2.6.37 pull request mentions new write-back helpers so that Btrfs can kick-off I/O to reclaim de-allocated space, performance improvements around ENOSPC, bug fixes, block group caching code, and various other clean-ups. When using the space_cache mount option for Btrfs to enable the block group caching the speed is supposed to be up dramatically as the b-tree is no longer scanned looking for free blocks. We will have a test of this shortly.

If you enjoyed this article consider joining Phoronix Premium to view this site ad-free, multi-page articles on a single page, and other benefits. PayPal or Stripe tips are also graciously accepted. Thanks for your support.


Related Articles
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.