Back to Linux page of KG

It does the following benchmarks:

char output with putc() / putc_unlocked()

The result is the performance a program will see that uses putc() to write single characters. On most systems, the speed for this is limited by the overhead of the library calls into the libc, not by the underlying device. The _unlocked version (used if bonnie is called with -u) may be considerably faster, as it involves less overhead.

char input with getc() / getc_unlocked()

The result is the performance a program will see that uses getc() to read single characters. The same comments apply as to putc().

block output with write()

The speed with which your program can output data to the underlying filesystem and device writing blocks to a file with write(). As writes are buffered on most systems, you will see numbers that are much higher than the actual speed of your device, unless you sync() after the writes (option -y) or use a considerably larger size for your testfile than your OS will buffer. For Linux, this is almost all your main memory.
If called with the -o_direct option, this operation (and the ones described in the following two paragraphs) are done with the O_DIRECT flag set, which results in direct DMA from your hardware to userspace, thus avoiding CPU overhead copying buffers around. This will prevent buffering, and gives a much better estimate of real hardware speed also for small test sizes.

block input with read()

The speed with which you can read blocks of data from a file with read(). The same comment as for block output regarding your OS doing buffering for you applies. With the exception that using -y does not help to get realistic numbers for reading. You would need to flush the buffers of the underlying block device, but this turns out to not be trivial as you first have to find out the block device ... It'd a be Linux only feature anyway.

block in/out rewrite

bonnie does a read(), changes a few bytes, write()s the data back and reread()s it. This is pattern that occurs e.g. on some database applications. Its result tells you how your operating / file system can handle such access patterns.

Seeks

Multiple processes do random lseek(). The idea of using multiple processes is to always have outstanding lseek() requests, so the device (disk) stays busy. Seek time is an indication, how good your OS can order seeks and how fast your hardware actually can do random accesses.

The original author (Tim Bray) has also put a description of bonnie on his pages.

As his results are rather old, I give here one from an Athlon-700 on a Asus K7V board with 256MB of RAM and a Maxtor 92041U4 hard disk (20GB) using UDMA/66 mode operated by Linux-2.2.16 (SuSE, includes Andre Hedrick's IDE patches). The measurement was done on a 1GB ext2 FS in the outer (fastest) zone of the hard disk by calling bonnie -s 400:

              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU
gum07. 1* 400  8701 93.2 26069 14.6 10337 12.2  7950 81.5 23695 11.2  122.1  1.5

Status

README for Bonnie

• breakhandler that deletes the test files created in case bonnie gets interrupted
• output a warning if the test file size is smaller than the amount of memory -- this will probably yield numbers that are much better than the actual speed of the device
• option -y to use fsync() after data has been written
• slightly improved option parsing
• options -p and -S to influence the seeker params
• machine name defaults to the hostname
• option -u to use getc_/putc_unlocked() instead of getc/putc()

I called the result bonnie-1.2 and put it on my web site http://www.garloff.de/kurt/linux/bonnie/ hoping that it would be useful for somebody.

New things in 1.3

• Fixed html output (thanks to Rupert Kolb)
• Support for -o_direct (thanks to Chris Mason / Andrea Arcangeli)

New things in 1.4

• Fixed a compile problem (related to direct IO support)
• Use small chunks for seek test. Bonnie-1.3 reported much too low seek numbers as it used very large reads after each seek.

The original maintainer was found and passed bonnie maintainership to me. So, I'll maintain it.

Kurt Garloff <garloff@suse.de>, 2/2002.

Download

• source tar ball, gzipped
• source tar ball, bzipped2
• source RPM (SuSE Linux)
• i386 binary RPM (SuSE Linux 7.1+)
• alpha binary RPM (SuSE Linux 7.1+)

Copyright & Acknowledgements

Bonnie++