Bonnie++はopenSUSE 10.3（1-クリック・インストール）、Ubuntu Hardy、標準のFedora 9リポジトリなどから入手可能だ。今回は64ビット用Fedora 9リポジトリからインストールした。
Bonnie++はUbuntu用とFedora用のパッケージでは/usr/sbinにインストールされるのに対してopenSUSEでは/usr/binにインストールされる。ルートユーザとして起動するとエラーが出て実行できないのだが、/usr/binではなく/usr/sbinにインストールしてある場合、通常のユーザとして実行するためにはフルパスを指定する必要がおそらくあるだろう。Bonnie++ではautoconfを使ってMakefileを生成するのだが、install-binターゲットで固定的にBonnie++をsbinにインストールするようになっているので、/usr/binに置きたい場合には、ソースから構築している場合でもインストール後に移動する必要がある。
Bonnie++では、データの読み書きを行う速度、1秒間に行うことのできるシークの回数、1秒間に行うことのできるファイルのメタデータの操作回数という3つの項目についてのベンチマークが可能だ。メタデータ操作には、ファイルの作成/削除と、ファイルの大きさや所有者などのメタデータ（fstat(2) システムコールの結果）の取得とがある。
例えば/tmpに使用するファイルシステムを選ぶ場合には、決め手となるベンチマーク項目はメタデータのスループットかもしれない。20MBのtarファイルを展開する場所用のファイルシステムでは、1秒間に作成可能なファイル数の方が書き込みについての性能よりも重要になるだろう。同様に、Squidウェブプロキシの使用や、各メールをそれぞれ別々のファイルに保存するmaildir形式を採用しているメールサーバの使用を検討している場合にもメタデータのベンチマークは重要だ。そのようなアプリケーションでは大量のメタデータ操作が何度も行なわれるが、各ファイルの容量は概してかなり小さいので、大量データの転送速度よりもメタデータの更新速度の方が重要な要素になる。
メタデータのベンチマークはまた、RAIDデバイス上にファイルシステムを新しく作成する場合にも重要だ。ジャーナリングファイルシステムは、ジャーナル内のメタデータを保護するために書き込みバリアを使用していることがある。RAID機能のためにハードウェアRAIDカードを使用している場合、そのような書き込みバリアの存在によってRAIDカード上の全キャッシュとそのRAIDカード上でRAIDを構成している全ディスクとの同期が取られる可能性があって、その場合には性能が極端に低下してしまう。実例として私が最近試したケースを挙げれば、Adaptec 31205カード（12ポート）上のRAID-6と書き込みバリアを有効にしたXFSを使用したテストでは、1秒間に作成可能なファイル数は100に満たなかった。一方同じファイルシステムをマウントする際にXFSの書き込みバリアを明示的に無効にした場合では、1秒間に作成可能なファイル数は6,000近くにまで増加した。XFSの書き込みバリアを無効にすることを勧めるつもりはないが、このハードウェア構成のケースに限って言えば、バリアを無効にしてもデータが失われるリスクはない。
1秒間に可能なシーク回数については、ハードウェア構成の影響が非常に大きい。1台のディスクとRAIDとを比較してみたところ、RAID上のファイルシステムではディスクの台数を増やせばシーク数の増加が期待できるようだった。例えば1台のディスクと、2台のディスクを使ったRAID-0（ストライピング）構成と、6台のディスクを使ったRAID-0構成とを比べてみたところ、1台のディスクでは1秒間に可能なシーク回数が約200回だったのに対して、2台のストライピングでは約340回、6台のストライピングでは約533回だった。
データの読み書きのベンチマークとしては、キャラクタ単位の結果とブロック単位の結果とが表示される。キャラクタ単位のベンチマークは、一度に1文字のキャラクタの読み書き操作を行う標準ライブラリの呼び出しを使用して行われる。一方ブロック単位のベンチマークは、より大きなブロックを一度に転送する関数の呼び出しを使用して行われる。