The Linux 2.6.37 Kernel With EXT4 & Btrfs

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.