<div dir="ltr">Hi OmniOS people -<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>remote_wwn local_wwn sectors_request operation length_of_request</div><div><div>21000024ff48a0c2 21000024ff58fae9 16     write(10)                            8192            </div></div><div><div>21000024ff48a0c2 21000024ff58fae9 16     read(10)                             8192            </div><div>21000024ff58262e 21000024ff58fae9 16     write(10)                            8192            <br></div><div>21000024ff48a0c2 21000024ff58fae8 32     write(10)                            16384           </div></div><div><div>21000024ff48a0c2 21000024ff58fae9 128    read(16)                            65536            </div><div>21000024ff58262e 21000024ff58fae9 16     write(10)                            8192 </div></div><div><br></div><div>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.</div><div><br></div><div><div>21000024ff58262f 21000024ff58fae8 0      read(10)                             1048576         <br></div></div><div><div>21000024ff48a0c3 21000024ff58fae8 0      read(10)                             1048576         </div><div>21000024ff48a0c2 21000024ff58fae9 0      write(10)                            131072          </div><div>21000024ff58262f 21000024ff58fae9 0      read(10)                             1048576         </div></div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>My script is using fc:::xfer-start for a probe and the documentation I've found give the following variables:</div><div><br></div><div><div><div>Probes                         Variable  Type               Description</div><div>------                         --------  ----               -----------</div><div>fc:::xfer-start,               args[0]   conninfo_t *       connection info</div><div>fc:::xfer-done                 args[1]   fc_port_info_t *   local port info</div><div>                               args[2]   scsi_cmd_t *       SCSI command block</div><div>                               args[3]   fc_port_info_t *   remote port info</div><div>                               args[4]   fc_xferinfo_t *    data transfer info</div></div></div><div><br></div><div>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.</div><div><br></div><div>Thoughts or help?</div><div><br></div><div>thanks!</div><div>liam</div><div><br></div></div>