The lsscsi command is a real gem for digging though devices.

 

http://sg.danny.cz/scsi/lsscsi.html#mozTocId856130

 

For example, "lsscsi -g" will give you the mating for /dev/sd? to /dev/sg?

 

root@Tower9:~# lsscsi -g
[0:0:0:0]    disk    ATA      WDC WD5000KS-00M 07.0  /dev/sdj   /dev/sg10
[1:0:1:0]    disk    WDC      WD10EADS-00L5B1  R001  /dev/sda   /dev/sg0
[1:0:1:1]    disk    WDC      WD20EARS-00MVWB0 R001  /dev/sdb   /dev/sg1
[1:0:1:2]    disk    WDC      WD20EARS-00MVWB0 R001  /dev/sdc   /dev/sg2
[1:0:1:3]    disk    WDC      WD20EARS-00S8B1  R001  /dev/sdd   /dev/sg3
[1:0:1:4]    disk    WDC      WD20EARS-00MVWB0 R001  /dev/sde   /dev/sg4
[1:0:1:5]    disk    WDC      WD10EAVS-22D7B0  R001  /dev/sdf   /dev/sg5
[1:0:1:6]    disk    WDC      WD20EARS-60MVWB0 R001  /dev/sdg   /dev/sg6
[1:0:1:7]    disk    WDC      WD20EARX-00PASB0 R001  /dev/sdh   /dev/sg7
[1:0:4:0]    disk    Areca    RaidCacheVol     R001  /dev/sdi   /dev/sg8
[1:0:16:0]   process Areca    RAID controller  R001  -         /dev/sg9
[7:0:0:0]    disk    pqi      IntelligentStick 1.00  /dev/sdk   /dev/sg11

+1

 

It looks like it might make it so much easier to identify which disk is acting up when all the disk error says is ATA5.1

 

Joe L.

Added this to -rc5, but I don't see what info it returns that isn't already available.  Maybe gathering it all together is good I suppose.  I have not found a way to easily translate those "ata.N" messages to a specific device id - very frustrating.

That's actually easy.

 

Look in /sys/block/sdX to get the host number from the synlink

 

Then cat the unique_id file in /sys/class/scsi_host/[hostX] and that is the number in the "ata.N"

 

 

Here is a script, using lsscsi that maps sdX to ata.N

 

#!/bin/sh
#
# Bubbas sdX to ata.N mapping script
# 

DEVLIST=`lsscsi -g | grep ${1}`
tempAR=(${DEVLIST// / })

SCSI=${tempAR[0]} 
TYPE=${tempAR[1]}
VENDOR=${tempAR[2]}
MODEL=${tempAR[3]}
VER=${tempAR[4]}
SD_DEV=${tempAR[5]}
SG_DEV=${tempAR[6]}

tempAR=(${SCSI//\ })

SCSI_HOST=`echo ${tempAR[0]} | awk '{ print substr($0,2,4) }'`
SCSI_CHANNEL=${tempAR[1]}
SCSI_TARGET=${tempAR[2]}
SCSI_LUN=${tempAR[3]}

HOSTLIST=`lsscsi -H -t | grep "[$SCSI_HOST]"`

tempAR=(${HOSTLIST// / })
CLASS=${tempAR[1]}
TRANSPORT==${tempAR[2]}

ATA=`cat /sys/class/scsi_host/host$SCSI_HOST/unique_id`

echo "Device $1 is ata.$ATA"

 

Going the other way (from ata.N to /dev/sdX) is a little trickier, and you have to run through all the /sys/class/scsi_host/hostXX/unique_id files, but it can be scripted too.

Cool script, thanks!  The output is not valid for SAS controllers, but that's ok.

Interesting.  My Areca 1880 (SATA behind SAS) does not use ata.N for the drives on it.  What controllers in particular are you using?  If I have one laying around, I'll see if I can make the script robust.  But I do get an ata.N entry for every SATA port on the mobo, regardless of if a drive is attached or not.

AOC-SASLP-MV8

 

In this particular server all the attached devices show up as ata.0

AOC-SASLP-MV8

 

I have one of those... I'll see what I can come up with.  Did anyone ask SuperMicro about it?

I put a Samsung 1TB drive on one port, and this is what I see when the AOC-SASLP-MV8 is probed.

 

It assigned ata7 to the Samsung, but the unique_id file contains "0".

 

Jun  7 08:11:32 Tower9 kernel: scsi2 : mvsas
Jun  7 08:11:32 Tower9 kernel: drivers/scsi/mvsas/mv_sas.c 379:phy 1 byte dmaded.
Jun  7 08:11:32 Tower9 kernel: sas: phy-2:1 added to port-2:0, phy_mask:0x2 ( 100000000000000)
Jun  7 08:11:32 Tower9 kernel: sas: DOING DISCOVERY on port 0, pid:923
Jun  7 08:11:32 Tower9 kernel: drivers/scsi/mvsas/mv_sas.c 1503:found dev[0:5] is gone.
Jun  7 08:11:32 Tower9 kernel: sas: Enter sas_scsi_recover_host
Jun  7 08:11:32 Tower9 kernel: ata7: sas eh calling libata port error handler
Jun  7 08:11:32 Tower9 kernel: sas: sas_ata_hard_reset: Found ATA device.
Jun  7 08:11:32 Tower9 kernel: ata7.00: ATA-7: SAMSUNG HD103SI, 1AG01118, max UDMA7
Jun  7 08:11:32 Tower9 kernel: ata7.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
Jun  7 08:11:32 Tower9 kernel: ata7.00: configured for UDMA/133
Jun  7 08:11:32 Tower9 kernel: sas: --- Exit sas_scsi_recover_host
Jun  7 08:11:32 Tower9 kernel: scsi 2:0:0:0: Direct-Access     ATA      SAMSUNG HD103SI  1AG0 PQ: 0 ANSI: 5
Jun  7 08:11:32 Tower9 kernel: sd 2:0:0:0: [sdl] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
Jun  7 08:11:32 Tower9 kernel: sd 2:0:0:0: Attached scsi generic sg12 type 0

 

The ata.N is created in libata-core, and I believe it is up to the driver (in this case, mvsas) to handle the unique_id file in /sys/class/scsi_host/hostX.

 

Perhaps an e-mail to the mvsas gurus is in order.