[CentOS] How to map ata#.# numbers to /dev/sd numbers?

[Peter Kjellstrom]

On Thursday 28 January 2010, Stephen Harris wrote:
> [ Sorry to merge messages; I appear to have lost Peter's post, so I'm
> replying to Peter and Mark in the same message ]
>
> Peter Kjellstrom wrote:
> > > On Thursday 28 January 2010, Stephen Harris wrote:
> > >> to determine what ata7.01 maps to in terms of /dev/sd# values?
> > >
> > > This seems quite hard to do. The following hack will match scsi hosts
> > > to libata-driver + number:
>
> Hmm, interesting:
>
> % for d in /sys/class/scsi_host/host*
> do
>   echo "$d $(cat $d/proc_name) $(cat $d/unique_id)"
> done
> /sys/class/scsi_host/host0 ahci 1
> /sys/class/scsi_host/host1 ahci 2
> /sys/class/scsi_host/host2 ahci 3
> /sys/class/scsi_host/host3 ahci 4
> /sys/class/scsi_host/host4 ahci 5
> /sys/class/scsi_host/host5 ahci 6
> /sys/class/scsi_host/host6 sata_sil24 7
> /sys/class/scsi_host/host7 sata_sil24 8
> /sys/class/scsi_host/host8 usb-storage 0
>
> So in this case ata7 appears to map to host6.  Now the usb-storage entry
> looks odd.  Do I have to magically know that ahci and sata_sil24 both map
> to "ata" entries?

AFAICT, I'm afraid so :-/

> >From lsscsi I see, for host 6
>
> [6:0:0:0]    disk    ATA      ST31000340AS     SD15  /dev/sdc
> [6:1:0:0]    disk    ATA      ST31000340AS     SD15  /dev/sdd
> [6:2:0:0]    disk    ATA      ST31000340AS     SD15  /dev/sde
> [6:3:0:0]    disk    ATA      ST31000340AS     AD14  /dev/sdf
>
> So I have to guess the second number in ata#.# represents the LUN of the
> device on that bus, so ata7.1 -> host6 -> [6:1:0:0] -> sdd

The LUN is actually the last of the four digits, the 2nd one is target 
(host:target:device:lun), but yes, your observation seems correct.

> This looks like an unreliable method of detection.  But it may be possible!

Uhu

> m.roth at 5-cent.us wrote:
> > Have you checked dmesg? For example,
>
> Yeah, but dmesg has two problems that I can think of
> 1) it may disappear if the number of kernel messages grows sufficiently
> large
>
> 2) The ID number wasn't obvious
> scsi6 : sata_sil24
> scsi7 : sata_sil24
> ata7: SATA max UDMA/100 host m128 at 0xfe7fbf80 port 0xfe7fc000 irq 169
> ata8: SATA max UDMA/100 host m128 at 0xfe7fbf80 port 0xfe7fe000 irq 169
>
> How does that tell me ata7 matches scsi6?  We can't rely on ordering
> (see below).

That is basically why I tried to find a better way than "interpreting" dmesg, 
yes you can probably figure it out but man it's an ugly way...

> Further,
>
>   ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>   ata7.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9
>   ata7.00: hard resetting link
>   ata7.00: SATA link up 1.5 Gbps (SStatus 113 SControl 320)
>   ata7.01: hard resetting link
>   ata7.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>   ata7.02: hard resetting link
>   ata7.02: SATA link up 1.5 Gbps (SStatus 113 SControl 0)
>   ata7.03: hard resetting link
>   floppy0: no floppy controllers found
>   ata7.03: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>   ata7.04: hard resetting link
>   ata7.04: SATA link down (SStatus 0 SControl 320)
>   ata7.05: hard resetting link
>   ata7.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320)
>   ata7.00: ATA-8: ST31000340AS, SD15, max UDMA/133
>   ata7.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32)
>   ata7.00: configured for UDMA/100
>   ata7.01: ATA-8: ST31000340AS, SD15, max UDMA/133
>   ata7.01: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
>   ata7.01: configured for UDMA/100
>   ata7.02: ATA-8: ST31000340AS, SD15, max UDMA/133
>   ata7.02: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
>   ata7.02: configured for UDMA/100
>   ata7.03: ATA-8: ST31000340AS, AD14, max UDMA/133
>   ata7.03: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
>   ata7.03: configured for UDMA/100
>   ata7: EH complete
>     Vendor: Maxtor    Model: 6Y120P0           Rev: YAR4
>     Type:   Direct-Access                      ANSI SCSI revision: 02
>   SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
>   sdb: Write Protect is off
>   sdb: Mode Sense: 53 00 00 08
>   sdb: assuming drive cache: write through
>   SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
>   sdb: Write Protect is off
>   sdb: Mode Sense: 53 00 00 08
>   sdb: assuming drive cache: write through
>    sdb:<6>ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>   ata8.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9
>   ata8.00: hard resetting link
>   ata8.00: SATA link up 1.5 Gbps (SStatus 113 SControl 320)
>
> As can be seen, different parts of detection appear to be interleaved
> (floppy detection message, sdb detection message - disk in a USB disk
> enclosure!) so I can't seem to rely on ordering of messages in dmesg to
> accurately determine which device has been assigned what ID.

Some order can be relied on, some not. Bottom line, you can by experience and 
testing find a correct mapping from dmesg, but really there should be a 
better way.

/Peter

> dmesg really gets messy when you have lots of disks!
>
> Thanks for the feedback so far!