The main bonnie site is here What follows is form bonnies man page:
Bonnie: Filesystem Benchmark Program Bonnie tests the speed of file I/O using standard C library calls. It does reads and writes of blocks, testing for the limit of sustained data rate (usually limited by the drive or controller) and updates on a file (better simulating normal operating conditions and quite dependent on drive and OS optimisations). The per character read and write tests are generally limited by CPU speed only on current generation hardware. It takes some 35 SPECint92 to read or write a file at a rate of 1MB/s using getc() and putc(). The seek tests are dependent on the buffer cache size, since the fraction of disk blocks that fits into the buffer cache will be found without any disk operation and will contribute zero seek time readings. I.e. if the buffer cache is 16MB and the Bonnie test file is 32MB in size, then the seek time will come out as half its real value. The seek time includes rotational delay, and will thus always come out higher than specified for a drive.
2 September 96
NAME
bonnie - Unix filesystem performance benchmark
SYNOPSIS
bonnie [ -d scratch-dir ] [ -s size-in-Mb ] [ -m machine-
label ]
OPTIONS
-d scratch-dir
Directory to create working file in. Filesystem
must be large enough to accomodate the size of the
working file.
-s size-in-Mb
Size of the working file in megabytes. Defaults
size is 100 megabytes. The larger the better.
-m machine-label
Identifying label to use for the machine benchmark
is being run on.
DESCRIPTION
bonnie is a file system benchmark which attempts to study
bottlenecks - it is named 'Bonnie' for semi-obvious rea
sons.
Specifically, these are the types of filesystem activity
that have been observed to be bottlenecks in I/O-intensive
applications, in particular the text database work done in
connection with the New Oxford English Dictionary Project
at the University of Waterloo.
It performs a series of tests on a file of known size. By
default, that size is 100 Mb (but that's not enough - see
below). For each test, Bonnie reports the bytes processed
per elapsed second, per CPU second, and the % CPU usage
(user and system).
In each case, an attempt is made to keep optimizers from
noticing it's all bogus. The idea is to make sure that
these are real transfers to/from user space to the physi
cal disk. The tests are:
1. Sequential Output
1.1 Per-Character. The file is written using the putc()
stdio macro. The loop that does the writing should be
small enough to fit into any reasonable I-cache. The CPU
overhead here is that required to do the stdio code plus
the OS file space allocation.
1.2 Block. The file is created using write(2). The CPU
overhead should be just the OS file space allocation.
1.3 Rewrite. Each BUFSIZ of the file is read with
read(2), dirtied, and rewritten with write(2), requiring
an lseek(2). Since no space allocation is done, and the
I/O is well-localized, this should test the effectiveness
of the filesystem cache and the speed of data transfer.
2. Sequential Input
2.1 Per-Character. The file is read using the getc()
stdio macro. Once again, the inner loop is small. This
should exercise only stdio and sequential input.
2.2 Block. The file is read using read(2). This should
be a very pure test of sequential input performance.
3. Random Seeks
This test runs SeekProcCount processes in parallel, doing
a total of 4000 lseek()s to locations in the file speci
fied by random() in bsd systems, drand48() on sysV sys
tems. In each case, the block is read with read(2). In
10% of cases, it is dirtied and written back with
write(2).
The idea behind the SeekProcCount processes is to make
sure there's always a seek queued up.
AXIOM: For any unix filesystem, the effective number of
lseek(2) calls per second declines asymptotically to near
30, once the effect of caching is defeated.
The size of the file has a strong nonlinear effect on the
results of this test. Many Unix systems that have the
memory available will make aggressive efforts to cache the
whole thing, and report random I/O rates in the thousands
per second, which is ridiculous. As an extreme example,
an IBM RISC 6000 with 64 Mb of memory reported 3,722 per
second on a 50 Mb file. Some have argued that bypassing
the cache is artificial since the cache is just doing what
it's designed to. True, but in any application that
requires rapid random access to file(s) significantly
larger than main memory which is running on a system which
is doing significant other work, the caches will
inevitably max out. There is a hard limit hiding behind
the cache which has been observed by the author to be of
significant import in many situations - what we are trying
to do here is measure that number.
COPYRIGHT
Copyright (c) Tim Bray, 1990. Everybody is hereby granted
rights to use, copy, and modify this program, provided
only that this copyright notice and the disclaimer below
are preserved without change.
DISCLAIMER: This program is provided AS IS with no war
ranty of any kind, and The author makes no representation
with respect to the adequacy of this program for any par
ticular purpose or with respect to its adequacy to produce
any particular result, and The author shall not be liable
for loss or damage arising out of the use of this program
regardless of how sustained, and In no event shall the
author be liable for special, direct, indirect or conse
quential damage, loss, costs or fees or expenses of any
nature or kind.
BUGS
None known
AUTHOR
Tim Bray <tbray at watsol.waterloo.edu>