[ 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@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@0xfe7fbf80 port 0xfe7fc000 irq 169 ata8: SATA max UDMA/100 host m128@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!