[OpenIndiana-discuss] cryptic device naming?

Mark mark0x01 at gmail.com
Tue Nov 9 07:53:15 UTC 2010


The other variable here is the controller settings.
The LSI card can use persistent mappings forthe disks, so it's OS 
presented device is constant, regardless of what slot it is physically in.

This drove me nuts trying to figure out what was going on the first time 
I encountered it.

I now use lsiutil to make sure it is off.
Most cards seem to now have it off by default.

The Disk Bay Indicator function is still elusive.

On my Supermicro hardware I have both the ses and ipmi drivers from the 
last sxce release working with oi147, and a borrowed sestopo to confirm 
it is all visible.
Unfortunately it still didn't help the fm drivers turn on the leds yet.

I know it all works, as I have had the full "Sun Storage Software" 
running on it, and the locate works perfectly.


On 06/11/2010 12:36 p.m., McBofh wrote:
> On 6/11/10 07:41 AM, Roy Sigurd Karlsbakk wrote:
>>> You've _got_ cXtYdZ naming - it's just that the (Y) part is
>>> based on the target-port name property, which is generated
>>> from the device devid (closely related to the GUID).
>>>
>>> With your hba, which is using mpt_sas, you have MPxIO on by
>>> default, which is the direction that ON has been heading in
>>> for many years.
>>
>> Is it possible to turn mpxio off without ruining the rpool?
>
> Yes, but I don't recommend it. There's been a concerted effort
> to make MPxIO the default operating mode for several years, and
> with mpt_sas that was one of the driver design criteria.
>
>> Also, may this help me get around the problem with identifying the
>> drives?
>
> Possibly - depends on what the mpt_sas hba does under the hood.
> I don't recall whether it does the same thing as the mpt controller,
> then your chance of getting a "logical target-id" rather than
> a physical, hard, slot/bay number is slim.
>
> What you could do, otoh, is probe your ses device, look at
> the output from SES diagnostic pagecode 0xa, Additional Element
> Status and hope that the Element Index Present (EIP) bit is
> set to 1 in the pagecode response. If it is, then you can
> match up bay numbers with element index entries.
>
> Or you could run
>
> /usr/lib/fm/fmd/fmtopo -dV
>
> and see if you can get output like this:
>
>
> hc://:product-id=SUN-Storage-J4200:server-id=:chassis-id=0848QAJ001:serial=0820T4LXSA--------3LM4LXSA:part=SEAGATE-ST330055SSUN300G:revision=0B92/ses-enclosure=1/bay=0/disk=0
>
> group: protocol version: 1 stability: Private/Private
> resource fmri
> hc://:product-id=SUN-Storage-J4200:server-id=:chassis-id=0848QAJ001:serial=0820T4LXSA--------3LM4LXSA:part=SEAGATE-ST330055SSUN300G:revision=0B92/ses-enclosure=1/bay=0/disk=0
>
> label string SCSI Device 0
> FRU fmri
> hc://:product-id=SUN-Storage-J4200:server-id=:chassis-id=0848QAJ001:serial=0820T4LXSA--------3LM4LXSA:part=SEAGATE-ST330055SSUN300G:revision=0B92/ses-enclosure=1/bay=0/disk=0
>
> ASRU fmri
> dev:///:devid=id1,sd@n5000c5000b20566b//scsi_vhci/disk@g5000c5000b20566b
> group: authority version: 1 stability: Private/Private
> product-id string SUN-Storage-J4200
> chassis-id string 0848QAJ001
> server-id string
> group: storage version: 1 stability: Private/Private
> logical-disk string c0t5000C5000B20566Bd0
> manufacturer string SEAGATE
> model string ST330055SSUN300G
> serial-number string 0820T4LXSA 3LM4LXSA
> firmware-revision string 0B92
> capacity-in-bytes string 300000000000
> target-port-l0ids string[] [ "w5000c5000b205669" ]
> group: io version: 1 stability: Private/Private
> devfs-path string /scsi_vhci/disk at g5000c5000b20566b
> devid string id1,sd at n5000c5000b20566b
> phys-path string[] [
> "/pci at 0,0/pci8086,3605 at 2/pci8086,3500 at 0/pci8086,3514 at 1/pci1000,3150 at 0/disk at 19,0"
> ]
>
>
>
>
>>> You should be able to see useful information by running
>>>
>>> # cfgadm -lav
>>>
>>> eg,
>>>
>>> Ap_Id Receptacle Occupant Condition Information
>>> When Type Busy Phys_Id
>>> c3 connected configured unknown
>>> unavailable scsi-sas n
>>> /devices/pci at 0,0/pci10de,376 at a/pci1000,3150 at 0:scsi
>>> c3::0,0 connected configured unknown Client Device:
>>> /dev/dsk/c5t5000CCA00510A7CCd0s0(sd37)
>>
>> I tried that, and I got some of the same results. However, the sdXX
>> doesn't mape to the device port, but seem to map to some (to me)
>> random drive.
>
> I also recommend reviewing my presentation on devids and GUIDs:
>
> http://www.jmcp.homeunix.com/~jmcp/WhatIsAGuid.pdf
>
>
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss




More information about the OpenIndiana-discuss mailing list