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