**************************************************************************
* The following are additional notes on the iosnoop program.
*
* $Id: iosnoop_notes.txt,v 1.1.1.1 2015/09/30 22:01:09 christos Exp $
*
* COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
**************************************************************************


* What does the output represent?

The output is disk events - I/O operations that cause the disk to physically
read or write data. The output is not application I/O events which may be
absorbed by memory caches - many of which will be. The output really is
physical disk events.

iosnoop uses probes from the "io" provider - which traces the block device
driver before disk events happen. disk events. The stack goes like this,

       application
         |
         V
       syscall
         |
         V
       vfs
         |
         V
       ufs/zfs/...
         |
         V
       block device driver
         |
         V
       physical device driver
         |
         V
       disk

Due to caching (after vfs) few events will make it to the disk for iosnoop
to see. If you want to trace all I/O activity, try using syscall provider
based scripts first.


* What do the elapsed and delta times mean?

Glad you asked!

The times may *not* be as useful as they appear. I should also add that 
this quickly becomes a very complex topic,

There are two different delta times reported. -D prints the
elapsed time from the disk request (strategy) to the disk completion
iodone); -o prints the time for the disk to complete that event
since it's last event (time between iodones, or since idle->strategy).

The elapsed time is equivalent to the response time from the application
request to the application completion. The delta time resembles the
service time for this request (resembles means it will be generally 
correct, but not 100% accurate). The service time is the the time for the
disk to complete the request, after it has travelled through any bus or
queue.

buuuttt.... you need to think carefully about what these times mean before 
jumping to conclusions. For example,

   You troubleshoot an application by running iosnoop and filtering 
   on your application's PID. You notice large times for the disk events
   (responce, service, for this example it doesn't matter). 
   Does this mean there is a problem with that application?
   What could be happening is that a different application is also using
   the disks at the same time, and is causing the disk heads to seek to
   elsewhere on the disk surface - increasing both service and response time.

hmmm! so you can't just look at one application, one set of numbers, and
understand fully what is going on. 

But it gets worse. Disks implement "tagged queueing", where events in the
queue are reshuffeled to promote "elevator seeking" of the disk heads (this
reduces head seeking). So the time for a disk event can be effected not
just by the previous event (and previous location the heads had seeked to), 
but the surrounding events that enter the queue.

So the good and the bad. The good news is that iosnoop makes it easy to
fetch disk event data on a live system, the bad news is that understanding
all the data is not really easy.

For further information on disk measurements see,

   "How do disks really work?" - Adrian Cockcroft, SunWorld Online, June 1996
   "Sun Performance and Tuning" - Adrian Cockcroft, Richard Pettit
   "Solaris Internals" - Richard McDougall, Jim Mauro



* The output appears shuffled?

Read the answer to this in ALLsnoop_notes.txt.