The pulsing I / O patterns that you see are typical for applications where many / most of the records in the file system are asynchronous - this is because the file system will load records so that it can do a lot at the same time, in order to avoid one disk searching for a record . The most common example I can think of is writing database data — with the exception of the database write log, everything is usually written asynchronously; Other transactional access patterns are generally similar because they have write-to-write logs to recover if some asynchronous writes are lost on failure. This is a common access pattern and is not necessarily a problem, but it can become a problem when your disk is very fragmented and the file system cannot write everything in batches (causing a lot of requests, as you tried to avoid).
The DTrace / iotop error that you see means either an error in the DTrace implementation itself or in the iotop DTrace script. After iotop at the iotop source code (in /usr/bin/iotop on OS X), there are three io:::start callbacks that may be the culprits. There may be some kind of null access pointer in the script for some types of I / O, but it does not look likely based on the script probes and the io:::start arguments. Perhaps this is best solved with an Apple error message.