# [OmniOS-discuss] dtrace fibre channel questions

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

- Previous message: [OmniOS-discuss] libarchive and OmniOS - ACL support
- Next message: [OmniOS-discuss] LX Zone DTrace
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170112/86c04164/attachment.html>

- Previous message: [OmniOS-discuss] libarchive and OmniOS - ACL support
- Next message: [OmniOS-discuss] LX Zone DTrace
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list