Latency Bubbles follow up

Following on from the latency bubbles in your IO posting. I have been asked two questions about this post privately:

  1. How can you map those long numbers in the output into readable entries, eg sd0.

  2. How can I confirm that disksort has been turned off?

The first one just requires another glob of D:

##pragma D option quiet

#define SD_TO_DEVINFO(un) ((struct dev_info \*)((un)->un_sd->sd_dev))

#define DEV_NAME(un) \\
        stringof(`devnamesp[SD_TO_DEVINFO(un)->devi_major].dn_name) /\* ` \*/

#define DEV_INST(un) (SD_TO_DEVINFO(un)->devi_instance)


fbt:ssd:ssdstrategy:entry,
fbt:sd:sdstrategy:entry
{
        bstart[(struct buf \*)arg0] = timestamp;
}

fbt:ssd:ssdintr:entry,
fbt:sd:sdintr:entry
/ arg0 != 0 /
{
        this->buf = (struct buf \*)((struct scsi_pkt \*)arg0)->pkt_private;
}

fbt:ssd:ssdintr:entry,
fbt:sd:sdintr:entry
/ this->buf /
{
        this->priv = (struct sd_xbuf \*) this->buf->b_private;
}

fbt:ssd:ssdintr:entry,
fbt:sd:sdintr:entry
/ this->priv /
{
        this->un = this->priv->xb_un;
}

fbt:ssd:ssdintr:entry,
fbt:sd:sdintr:entry
/ this->buf && bstart[this->buf] && this->un /
{
        @l[DEV_NAME(this->un), DEV_INST(this->un)] =
                lquantize((timestamp - bstart[this->buf])/1000000, 0,
                60000, 60000);
        @q[DEV_NAME(this->un), DEV_INST(this->un)] =
                quantize((timestamp - bstart[this->buf])/1000000);
                bstart[this->buf] = 0;
}


The second required a little bit of mdb. Yes you can also get the same from dtrace mdb gives the the immediate answer, firstly for all the disks that use the sd driver and then for instance 1:

# echo '\*sd_state::walk softstate | ::print -at "struct sd_lun" un_f_disksort_disabled' | mdb -k
300000ad46b unsigned un_f_disksort_disabled = 0
60000e23f2b unsigned un_f_disksort_disabled = 0
# echo '\*sd_state::softstate 1 | ::print -at "struct sd_lun" un_f_disksort_disabled' | mdb -k
300000ad46b unsigned un_f_disksort_disabled = 0
Comments:

Very handy - how hard will it be to translate the sd0 device name to an even more readable /dev/[r]dsk/cXtYdZs2 device name?

Posted by Gordon Marler on February 27, 2008 at 07:10 PM GMT #

Within D trace it would be hard to convert the sdX numbers to cXtYdZ numbers. However post processing them is not beyond the wit of man. I leave it as an exercise of the reader;-)

Posted by Chris Gerhard on February 28, 2008 at 02:03 AM GMT #

Looks like someone else already solved this problem (sort of): http://blogs.sun.com/clive/entry/sdxx_to_cxtxdx_conversion_for

The Perl could be better, but I'm certainly not going to complain!

It would be \*very\* nice if a DTrace translator was provided that performed this kind of conversion, since the cXtYdZ device format is much more likely to be useful. Otherwise, there wouldn't be a -n option to iostat.

Posted by Gordon Marler on February 28, 2008 at 09:02 AM GMT #

Apologies in advance for what might seem like an obvious question, but I just want to be sure. So, does the value of zero shown in the example imply that disksort is disabled or enabled ?

Posted by Jeroen on February 29, 2008 at 05:25 AM GMT #

0 means disksort is enabled.

Posted by Chris Gerhard on February 29, 2008 at 05:30 AM GMT #

Thanks. I was hoping to try some benchmark tests on our 6140 with disksort enabled and disabled. I have modified simple kernel parameters before with mdb but am not sure how one would modify a parameter based on a structure. Could you provide an example, please ?

Posted by Jeroen on March 02, 2008 at 04:43 AM GMT #

You can find the 'friendly names' starting with /etc/path_to_inst.

PV=`egrep '"sd"$' /etc/path_to_inst | nawk '$2 == 1 { print $1 }' | tr '"' ' '`
ls -l /dev/dsk | egrep $PV | egrep s0 | nawk { print $9 }

will get you most of the way there if you're looking for sd1. Converting this to Perl is left as an exercise for the reader...

iostat does this with devfsadm but when I started doing the code for iostat, I had been parsing /etc/path_to_inst based on a script I received from Jeff Bonwick. devfsadm intervened before the code was put back.

Posted by James Litchfield on March 04, 2008 at 08:23 PM GMT #

Thanks for the follow up, posts like this are great help.

Posted by Alex Maidak on March 10, 2008 at 01:31 PM GMT #

Post a Comment:
Comments are closed for this entry.
About

This is the old blog of Chris Gerhard. It has mostly moved to http://chrisgerhard.wordpress.com

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today