3 ms·

If it's not reliable as claimed by the article, then does it really serve the purpose? There might be a code-path in an innocent little app that calls brk() oft

• brendangregg 12y ago
  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.