Tweet
Hello,
I fail understanding the reasons for the difference in the two following benchmarks I performed :
I/ CONDITIONS COMMON TO BOTH
Hardware (4G RAM), Kernel 2.6.38, Running services, Performance Governor, Noop IO scheduler...
Benchmark run : /usr/sbin/iozone -Raz -g 4G -+u -b SomeFileName.xls
Mount options : default
II/ CONDITIONS SPECIFIC TO THE FIRST BENCHMARK
The filesystem tested was created with the default mke2fs set of features for ext4, that is to say in extenso :
has_journal - ext_attr - resize_inode - dir_index - filetype - extent - flex_bg - sparse_super - large_file - huge_file - uninit_bg - dir_nlink - extra_isize
Block-size = 4096 - inode-ratio = 16.384 - inode_size = 256
Blocks reserved for root : 5%
III/ CONDITIONS SPECIFIC TO THE SECOND BENCHMARK
The filesystem tested in the second benchmark was created at the same geographical location on the disk but with different features :
Features not selected : resize_inode ; huge_file ; dir_nlink ; extra_isize
Block-size = 4096 - inode-ratio = 262144 - inode_size =128
Blocks reserved for root : 1%
IV/ RESULTS
The results show significant differences :
1/ Performances are boosted in the second benchmark on all operations (read, write...) on filesizes >= 1G that is to say above the caches/buffer-caches size I believe by 20 to 50%
However
2/ Reader / Re-Reader / Backward read / Stride read tests show a significant performance drop (about -20%) on operations on filesizes < 2M with +40 to +200% cpu consumption.
Could someone help me understanding point 2/
I fail understanding the reasons for the difference in the two following benchmarks I performed :
I/ CONDITIONS COMMON TO BOTH
Hardware (4G RAM), Kernel 2.6.38, Running services, Performance Governor, Noop IO scheduler...
Benchmark run : /usr/sbin/iozone -Raz -g 4G -+u -b SomeFileName.xls
Mount options : default
II/ CONDITIONS SPECIFIC TO THE FIRST BENCHMARK
The filesystem tested was created with the default mke2fs set of features for ext4, that is to say in extenso :
has_journal - ext_attr - resize_inode - dir_index - filetype - extent - flex_bg - sparse_super - large_file - huge_file - uninit_bg - dir_nlink - extra_isize
Block-size = 4096 - inode-ratio = 16.384 - inode_size = 256
Blocks reserved for root : 5%
III/ CONDITIONS SPECIFIC TO THE SECOND BENCHMARK
The filesystem tested in the second benchmark was created at the same geographical location on the disk but with different features :
Features not selected : resize_inode ; huge_file ; dir_nlink ; extra_isize
Block-size = 4096 - inode-ratio = 262144 - inode_size =128
Blocks reserved for root : 1%
IV/ RESULTS
The results show significant differences :
1/ Performances are boosted in the second benchmark on all operations (read, write...) on filesizes >= 1G that is to say above the caches/buffer-caches size I believe by 20 to 50%
However
2/ Reader / Re-Reader / Backward read / Stride read tests show a significant performance drop (about -20%) on operations on filesizes < 2M with +40 to +200% cpu consumption.
Could someone help me understanding point 2/