[OmniOS-discuss] dtrace fibre channel questions

Liam Slusser lslusser at gmail.com
Fri Jan 13 02:29:10 UTC 2017


Hi OmniOS people -

Looks like the dtrace mailing list is pretty quiet so I hope you guys don't
mind me ask a question here.  If you can recommend a better list please let
me know.

I am writing a dtrace script to snoop on COMSTAR fibre channel target
provider on a OmniOS server sharing a ZFS pool.  I've run into a few
problems I can't seem to figure out.

Using a few dtrace iscsi scripts I've found online I was able to write
something that can watch the scsi-commands via the dtrace
probe fc:::xfer-start.  The output looks something like this:

remote_wwn local_wwn sectors_request operation length_of_request
21000024ff48a0c2 21000024ff58fae9 16     write(10)
   8192
21000024ff48a0c2 21000024ff58fae9 16     read(10)
  8192
21000024ff58262e 21000024ff58fae9 16     write(10)
   8192
21000024ff48a0c2 21000024ff58fae8 32     write(10)
   16384
21000024ff48a0c2 21000024ff58fae9 128    read(16)
 65536
21000024ff58262e 21000024ff58fae9 16     write(10)
   8192

So basically the number before the operation name (read/write) is the
number of sectors requested which I pull from the ic_cdb packet.  I get the
request length from fcx_len. Now since each sector is 512k you can do the
easy math to verify sector request size * 512 = fcx_len. And it does indeed
add up.  What I don't understand is some requests look like this.

21000024ff58262f 21000024ff58fae8 0      read(10)
  1048576
21000024ff48a0c3 21000024ff58fae8 0      read(10)
  1048576
21000024ff48a0c2 21000024ff58fae9 0      write(10)
   131072
21000024ff58262f 21000024ff58fae9 0      read(10)
  1048576

I don't understand why some requests have a 0 sector transfer length in the
ic_cdb packet but a large request length in the fcx_len.  They almost
always are 1048576 in size, but not always like in the case of the
write(10) above.  The few scripts and one-liners I've seen that do sums of
traffic don't seem to discard these requests.  Anybody know what they are?

I also am unable to figure out what target LUN each request is going to.
The COMSTAR protocol for iscsi has iscsiinfo_t which gives exactly what I'm
looking for but there doesn't seem to be a fcinfo_t struct unfortunately.
How can I map a request from the probe fc:::xfer-start to a zfs zpool?

My script is using fc:::xfer-start for a probe and the documentation I've
found give the following variables:

Probes                         Variable  Type               Description
------                         --------  ----               -----------
fc:::xfer-start,               args[0]   conninfo_t *       connection info
fc:::xfer-done                 args[1]   fc_port_info_t *   local port info
                               args[2]   scsi_cmd_t *       SCSI command
block
                               args[3]   fc_port_info_t *   remote port info
                               args[4]   fc_xferinfo_t *    data transfer
info

I've looked through all those variables and I can't find anything that
points to a LUN/target.  I figure it can be done because I am able to get
those stats on our Oracle zfssa which uses dtrace for its reporting.

Thoughts or help?

thanks!
liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20170112/86c04164/attachment.html>


More information about the OmniOS-discuss mailing list