Iosnoop For Linux

fs_usage is a useful tool; the original version of iosnoop(1m) has also been available since Dtrace was added to OS X 10.5.

There's sc_usage too for cumulative display of all system calls.

He also has a slide about OSX performance:

http://www.slideshare.net/brendangregg/analyzing-os-x-system...

You can use it to study block device I/O details, confirming latency outliers, and analyzing device, size, and offset patterns. It's the COMM and PID columns that aren't reliable -- they show what's on-CPU at the time of block device issue, which is usually the origin PID, but sometimes not. This has always been the case for iosnoop (all versions). I'm explaining this caveat better today than I have in the past.

As for the origin PID... I usually trace that from a different layer of the stack (vfs, file system, or syscall). But this approach has different caveats: the overhead is much higher (more frequent requests), and if I want to associate it with the block I/O, then many solutions are going to require debuginfo, and/or a different tracer. Also, what if a process buffers minutes of disk I/O then exits, and then that PID is reused by a different process calling disk I/O? It's a remote possibility, but I just wanted to mention another problem in this area.