A Filemark execution includes three phases: creation, transaction, and delete phase. The transaction phase includes file read and append operations, and some file creation and removal operations. The configuration we used in this test is the so called ``medium system'' mentioned in Bryant's Linux filesystem performance study [3]. Here we run filemark with 4 target directories, each on a different disk, 2000 subdirectories per target directory, and 100,000 total files. The file sizes ranged from 4KB to 16KB and the I/O size was 4KB. Figure 3 shows the average transactions per second during the transaction phase, when running Filemark with 1, 8, 64, and 128 threads on the three kernels.
This benchmark uses a varying number of threads. We therefore expected the scalability improvements to the ext3 filesystem in the 2.6 kernel should improve Linux 2.6's performance for this benchmark. In addition, during the transaction phase, some files are deleted soon after the benchmark creates or appends data to those files. The delayed allocation could avoid the need for disk updates for metadata changes at all. So we expected Alex's delayed allocation to improve the throughput on this benchmark as well.
The results are shown in Figure 3. At 128 threads, we see that the 2.4.29 kernel had significant scalability problems, which were addressed in the 2.6.10 kernel. At up to 64 threads, there is approximately a 10% to 15% improvement in the transaction rate between Linux 2.4.29 and Linux 2.6.10. With the extents patch set applied to Linux 2.6.10, the transaction rate is increased another 10% at 64 threads. In the future, we plan to do futher work to determine how much of the additional 10% improvement can be ascribed to the different components of the extents patch set.
More performance results, both of the benchmark tests described above, and additional benchmark tests expected to be done before the 2005 OLS conference can be found at http://ext2.sourceforge.net/ols05-testing.