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

Stephen Harris lists at spuddy.org
Thu Jan 28 22:05:41 UTC 2010


[ 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?

>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

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

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).

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.

dmesg really gets messy when you have lots of disks!

Thanks for the feedback so far!

-- 

rgds
Stephen



More information about the CentOS mailing list