This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Issues with System Tap + iostat-scsi.stp + IBM Tape Drives
Hi, Andy -
andy.wojnarek wrote:
> I'm trying to use STAP and iostat-scsi to gather tape drive
> performance statistics on my tape drives. I can't get any
> information from tape drives though. [...]
> I am only getting disk stats: [...]
>
> ls -al /dev/tape/by-id
> lrwxrwxrwx 1 root root 9 Dec 27 13:05 scsi-1IBM_3573-TL_00L4U78P6926_LL0-changer -> ../../sg5
> lrwxrwxrwx 1 root root 9 Dec 27 13:05 scsi-32001000e111443b5-sg -> ../../sg4
> lrwxrwxrwx 1 root root 9 Dec 27 13:05 scsi-32004000e111443b5-sg -> ../../sg3
> If you could point me in the right direction I'd REALLY appreciate
> it. STAP is literally the only way I've found to get performance
> from scsi tape drives.
OK. If the two probes in iostat-scsi.stp aren't catching this type of
tape drive traffic, try some tracing to figure out where the traffic
is going instead.
# stap .../para-callgraph.stp 'module("sg").function("*")' -c 'tape operation'
# stap .../para-callgraph.stp 'module("st").function("*")' -c 'tape operation'
to see what's up. It may be that probing at a lower level, like
sg_start_req(), decoding the Sg_request struct (fields in srp->header)
can give the same device-name / transfer-size-direction data as the
sd_mod / st probes do.
> It's 2012 and there is still nothing easy that allows this to
> happen. On AIX, I can do iostat -p and it will show me the tape
> drives.
I get the sense more recent kernels have added some exposure of tape
drives to iostat or blktrace or something else, but don't have a
specific pointer.
- FChE