While we have already delivered a number of benchmarks from the Linux 2.6.39 kernel, surprisingly we have not yet published any new file-system benchmarks from this latest stable Linux kernel release. Fortunately, that has changed today with a fresh round of Btrfs, EXT4, and XFS file-system benchmarks on the Linux 2.6.39 kernel and compared to the preceding 2.6.38 and 2.6.37 kernel releases.
By now, you are likely used to our file-system benchmarks. Each file-system was tested with its default mount options under each kernel release (Linux 2.6.37, 2.6.38, and 2.6.39). Via the Phoronix Test Suite and OpenBenchmarking.org were the Apache, PostMark, SQLite, Dbench, Flexible I/O Tester, FS-Mark, Threaded I/O Tester, and IOzone benchmarks.
The system used to facilitate this testing was a Lenovo ThinkPad T61 with an Intel Core 2 Duo T9300 processor, 4GB of system memory, 100GB Hitachi HTS72201 SATA HDD, and NVIDIA Quadro NVS 140M graphics. The file-system benchmarking was done on an Ubuntu 11.04 x86_64 installation with the 2.6.37/2.6.37/2.6.39 vanilla kernels.
Starting with the Apache web-server benchmark, there is a clear pullback in performance on the Linux 2.6.39 kernel across all three file-systems by a measure of 8~14%. Thus it does not look like it is a regression that happens to be within each of file-system kernel modules, but likely somewhere else in the kernel causing the degradation.
The EXT4 and Btrfs file-systems were largely unchanged when upgrading to the Linux 2.6.39 kernel. However, with XFS there is one hell of an improvement with the performance going up by 6.4x for the PostMark mail server benchmark. This actually makes XFS the fastest file-system for PostMark on the 2.6.39 kernel among Btrfs, XFS, and EXT4.
There are a variety of improvements to the XFS file-system in the 2.6.39 kernel, including optimized busy extent tracking and various bug-fixes. From the XFS status update, "April saw further stabilization work on the Linux 2.6.39 kernel, including a number of XFS bug fixes. Most importantly, a series of patches fixes various OOM problems due to bad interactions between the generic write-back code and XFS inode reclaim, but there also were other patches for various smaller issues. In the meantime the XFS development tree saw the addition of the optimized busy extent tracking, which allows large speedups for multi-threaded meta data heavy workloads, and lays the groundwork for discard support on transaction commit, and a few other smaller patches."