Left Arrow Back to Linux page of KG


Bonnie is a simple but useful tool to determine the speed of your filesystem, your OS' caching, the underlying device and your libc.

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.
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


Why the bonnie program can be found here and what changes I have done to it.

README for Bonnie

I was wondering, who was maintaining bonnie, as I had a few improvements for it. As nobody could be found (I did not try very hard that time I have to admit), I just looked out for the latest bonnie versions, applied the bigbonnie patches that I also found out there. I put everything together and implemented the changes I had in mind: I hope I didn't break portability. I did try to use the correct #ifdefs to allow for compilation on different systems. Unfortunately, I could only test onLinux and DEC OSF 4.

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

New things in 1.4

New in 1.5

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

Kurt Garloff <kurt@garloff.de>, 2/2012.


Find here the sources of bonnie-1.5:
  • source tar ball, bzipped2
  • Binaries for various Linux distributions can be found in my storage repository on openSUSE Build Service.

    Old version ...

    Find here the sources and binaries of bonnie-1.4: Installation and compilation should be straight forward. For Linux, your easiest option is to use rpm --rebuild on the source RPM. If you use Linux (preferably SuSE Linux) with a i386 machine, you can even use the binary RPM.

    Copyright & Acknowledgements

    The original author Tim Bray <tbray@textuality.com> put bonnie under an artistic license, and neither Jelle Foks (bigbonnie) nor me changed this. Thanks are due to them for their work! Tim added some guidelines.


    Andreas Dilger dropped me a note that there is another maintained version of bonnie out there: bonnie++ maintained by Russell Coker.
    I'll have a look and check whether the efforts can be merged.
    (w) by KG, last changed 2012-02-04