[OpenIndiana-discuss] cryptic device naming?

[McBofh]

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