[nkurz]

You make good points, and I hadn't considered how the VM would affect things. I'm still doubtful that frequent rewrites of the same file would actually hit the flash of the SSD, but with much less certainty. If it is writing this frequently, this seems like a place for an easy optimization of the VM. Or maybe I'm misunderstanding, and it's writing a series of small files rather than rewriting the same one?

[michaelrash]

On the VM, AFL is rewriting the same small file millions of times, and the fuzzed program is reading this file from disk (as opposed to stdin). I think the main question is why does the OS X activity monitor show a massive spike in disk writes when AFL is started and a corresponding decrease when it is stopped? This is 100% reproducible, and the magnitude of the change is unmistakable. It is absolutely clear that the spike in disk writes is due to AFL activity. Further, this same spike does not happen when running under a RAM disk on the VM. I'm confident you would see the same result. So, either the OS X activity monitor has some special way to measure caching in the VM and that is what it is showing (surely this is unlikely), or the writes really are hitting the SSD when not running under the RAM disk. If not the later, what other (realistic) possibility is there?

[nkurz]

How about this interpretation (which is only a guess, although I think it's likely):

Activity Monitor does not distinguish between cache hits and misses, and counts the number of reads and writes to the host filesystem rather than summing the requests to the physical devices. Parallels presents the guest with a virtual filesystem, and the device driver for this filesystem does no caching of its own, as this would waste memory due to double caching. Instead, it merely passes requests through to the real filesystem on the host. These requests (read or write) produce system calls, and this is what is being reported in Activity Monitor regardless of whether they use the page cache or physical SSD.

One way to test this would be to use DTrace, which can distinguish between requests to the filesystem and activity that reaches the device. The scripts "hfsslower.d" and "iosnoop" are here: http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scr...

[michaelrash]

Ok, that sounds like a reasonable alternative, and Brendan Greeg is certainly a powerful force in this area. I'll run dtrace and see what happens, but I'm going to let a current long-running fuzzing run finish first.