I’m confident that many of you have seen this countless times when using the popular “standard” harddisk benchmarking tool, Bonnie++:

# bonnie++ -u root -d /mnt/1
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
grml             8G 51447  98 129399  39 56253  16 43505  97 136526  16 985.2   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

The manpage explains this as follows:

If a test completes in less than 500ms then the output will be displayed as “++++”. This is because such a test result can’t be calculated accurately due to rounding errors and I would rather display no result than a wrong result.

You will most likely see this for the lower “Create” section of Bonnie++. While the tests from the upper “Input/Output” section always make an educated guess and use twice the size of RAM, the “Create” tests have no way of guessing the proper number of files. Look for the word “files” near the left: Bonnie++ always defaults to this 16 x 1024 files for testing. Indeed, munging 16000 files in less than half a second sounds like no big task for a fast system.

Bonnie++ takes an option that instructs it to use more files for the “Create” tests, e.g. -n 128 tells it to test with 128 x 1024 files. In this second run, I’ll also disable the “Input/Output” tests by setting -s0:

# bonnie++ -u root -d /mnt/1 -s 0 -n 128
Version 1.03d       ------Sequential Create------ --------Random Create--------
grml                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                128 46336  84 +++++ +++ 31277  50 32574  65 +++++ +++ 12803  23

We now get values for file creation and deletion, but reads are still excessively fast. Since Bonnie++ discarded the measurement because it finished within less than 500 ms, it may be possible to estimate that the system is capable of performing at least (128 x 1024 x 2 = 262144) read operations per second.

Further increasing the number may not be possible due to lack of inodes on your filesystem. Also, such an extremely high number of files and file operations may decrease overall file system performance.
The system used for testing was a dual AMD Opteron 285 with a hardware RAID 0 of 3 UW320 disks @ 15k RPM.