I want to test the performance of a NAS before and after I change its setup. I have found two tools for this, fio and bonnie++.

The problem is that they are both broken on Mac right now (and have been for some time it seems). fio doesn't compile (Due to changes in XCode 8?) and bonnie fails to complete successfully (it fails on machines with more than 1 GB memory and also fails when it tries to clean up the files it created).

How can I test the performance of a NAS on a Mac? I am mostly interested in the relative performance, that is, how much the performance change when I make this change in configuration that I am about to try out, which I assume makes it easier?

(Or does it exist some static compiled fio/bonnie that works on current Mac OS?)

  • Is this really a question that's in scope for this site? At its heart, you want to determine the performance of a non-Apple device, the NAS. This looks off topic to me.
    – fsb
    Oct 13, 2020 at 20:16
  • @fsb Access performance can only be tested from a client which in this case seems to be a Mac
    – nohillside
    Oct 13, 2020 at 20:19
  • Did you check whether these tools are available via homebrew or macports?
    – nohillside
    Oct 13, 2020 at 20:22
  • @nohillside Bonnie 1.97 is available via MacPorts but doesn't work. I downloaded the source for Bonne 2.0x and compiled, but it hade the same problem. There might be a fork of Bonnie in Homebrew that might work but I would like to avoid installing HB for just one tool.
    – d-b
    Oct 13, 2020 at 20:32
  • 1
    @fab Yes it is, since I need to run it on a Mac. That is the core question.
    – d-b
    Oct 13, 2020 at 23:26

1 Answer 1


Bonnie++ can be installed this way:

Download Bonnie++ 1.98 from here:


Extract the source code:

tar -xvzf bonnie++-1.98.tgz

Download the patch found here:


Apply it to the source code using the patch utility:

cd bonnie++-1.98
patch < ../remove-large-file-support-macros.diff

Now configure and compile like usual:

make install
  • Still doesn't work. After a looong time, it quits with Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty although I at least could set -r to more than 1 GB.
    – d-b
    Oct 13, 2020 at 23:29
  • What is the exact command line you start bonnie with? Are any of the paths on a networked file system? - If so which? (NFS, SMB, or?)
    – jksoegaard
    Oct 14, 2020 at 8:31
  • $ bonnie++ -r 16384 -d /Volumes/tmp - it is on a volume mounted via AFP.
    – d-b
    Oct 14, 2020 at 8:41
  • It seems to be a problem with testing devices mounted via AFP (and possibly other network protocols). There are simply too many files in one directory to delete and for some reason bonnie chokes on that. I added -n 1:0:0:100: to my command, which, I think, run everything as default except it creates 100 directories and split the files it creates evenly among those directories. Now, with much fewer files in each directory, cleaning up them seemed to have worked fine.
    – d-b
    Oct 15, 2020 at 13:58
  • Yes, that’s why I asked if it is networked. Bonnie is special in that it does a readdir() while changing things in the directory - works fine locally, but requires a networked file system to be fully POSIX compliant, which they often aren’t. There’s a patch around that makes it restart the readdir() (rewind) on every loop - makes it work with buggy NFS servers as well.
    – jksoegaard
    Oct 15, 2020 at 15:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .