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@xxxxxxxxx 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).
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!
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
