Tom Zanussi's blktap* scripts should get included in our samples and/or wiki. While it relies on the blktrace system being turned on via its own userspace, the forthcoming marker-based blktrace should be workable without that. http://www.sourceware.org/ml/systemtap/2007-q1/msg00485.html
The blktap code has five example scripts: countall.stp - display counts of all blktrace events spectest.stp - test 'speculative tracing' support iotop.stp - periodically display top I/O producers topfile.stp - display read/write I/O accumulated by file traceread.stp - trace read I/O for all or selected file Each example needs blktrace running to trigger the data collection because the tapset probes kernel.function("_blk_add_trace"). There are some additional probes in the kernel for kernel.function ("__set_page_dirty_nobuffers"). Didn't get any counts for the countall.stp or the other example scripts. The bundling of the default handler functions in in the tapsets/blktrace.stp blocks the real ones in countall.stp script from being used. I was able to veryify that __blk_add_trace was operating with the following script: $ stap -I tapsets -e 'global c probe kernel.function("__blk_add_trace") { c[$what]++ } probe end {foreach (w+ in c) printf("c[0x%x] = %d\n", w, c[w]) }' c[0x100001] = 2235 c[0x100002] = 2071 c[0x100004] = 164 c[0x100009] = 21 c[0x10000f] = 4470 c[0x110000c] = 164 c[0x1400007] = 162 c[0x1800008] = 162 partical list of things to fix: -break out the default handler functions into separate files -probe the tracepoint locations rather than __blk_add_trace (reduce overhead and eliminate need for blktrace to run) -address the deref() and access to data structure issues -make spectest.stp use the existing speculative.stp
I'd rather investigate the more modern ioblame facilities.