mapping ataXX.YY to a /dev/sdX

mapping ataXX.YY to a /dev/sdX

[Mikael Abrahamsson]

Hi.

I have some spurious timeouts (but without md kicking the drive) on an 
WD20EADS. I believe this drive is actually defective and would like to 
swap it.

Looking at dmesg etc, I don't see an exact mapping between /dev/sdX and 
the ataXX.YY semantics. I can guess with high probability which drive this 
is, but I don't know for sure and I don't want to fail the wrong drive.

Anybody know a sure way to find this mapping out? Been looking in /sys 
etc, but no go so far...

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: mapping ataXX.YY to a /dev/sdX

[Daniel Pittman]

Mikael Abrahamsson <swmike@swm.pp.se> writes:

> I have some spurious timeouts (but without md kicking the drive) on an
> WD20EADS. I believe this drive is actually defective and would like to swap
> it.
>
> Looking at dmesg etc, I don't see an exact mapping between /dev/sdX and the
> ataXX.YY semantics. I can guess with high probability which drive this is, but
> I don't know for sure and I don't want to fail the wrong drive.
>
> Anybody know a sure way to find this mapping out? Been looking in /sys etc,
> but no go so far...

No.  OTOH, the poor sysadmins version of the "disk identification light" is:

    sudo dd if=/dev/sdFAIL of=/dev/null

...plus a pair of eyes.  FWIW.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mapping ataXX.YY to a /dev/sdX

[Mikael Abrahamsson]

On Wed, 7 Jul 2010, Daniel Pittman wrote:

> No.  OTOH, the poor sysadmins version of the "disk identification light" is:
>
>    sudo dd if=/dev/sdFAIL of=/dev/null
>
> ...plus a pair of eyes.  FWIW.

Yeah, if the drive is failed or if I know what drive to access I have no 
problem identifying it (I can access the working array and see what drive 
slots blink and which don't, or try to access the failed drive). But I 
have right now no way to identify the drive on "ata14.00". I can from 
dmesg deduce that it's most likely /dev/sdj (by observing the order of 
things being identified), but I don't know for sure it seems.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: mapping ataXX.YY to a /dev/sdX

[Tim Small]

Mikael Abrahamsson wrote:
> On Wed, 7 Jul 2010, Daniel Pittman wrote:
>
>> No.  OTOH, the poor sysadmins version of the "disk identification
>> light" is:
>>
>>    sudo dd if=/dev/sdFAIL of=/dev/null
>>
>> ...plus a pair of eyes.  FWIW.
>
> Yeah, if the drive is failed or if I know what drive to access I have
> no problem identifying it (I can access the working array and see what
> drive slots blink and which don't, or try to access the failed drive).
> But I have right now no way to identify the drive on "ata14.00". I can
> from dmesg deduce that it's most likely /dev/sdj (by observing the
> order of things being identified), but I don't know for sure it seems.
>

Whilst SCSI drives have the ability to blink the activity light, I don't
think SATA drives have this (BICBW).  Are these links any use to you:

root@ermintrude:~# ls
'/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block'
sda

?

Could you access all the other drives, and thus eliminate them from your
enquiries?  Bit naff, but better than nothing...

Tim.

Re: mapping ataXX.YY to a /dev/sdX

[Mikael Abrahamsson]

On Thu, 8 Jul 2010, Tim Small wrote:

> Whilst SCSI drives have the ability to blink the activity light, I don't 
> think SATA drives have this (BICBW).  Are these links any use to you:

Well, I still wouldn't know what drive to blink right, because the tool 
would unlikely accept "ata14.00" for sending commands to?

> root@ermintrude:~# ls
> '/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block'
> sda

It seems the driver doesn't implement that, I can see it for the 
ICH10R-controller, but not for the SiL-based one this drive is on:

[    1.289345] ahci 0000:08:00.0: setting latency timer to 64
[    1.289436] scsi12 : ahci
[    1.289501] scsi13 : ahci
[    1.289542] ata13: SATA max UDMA/133 abar m2048@0xfbeff000 port 0xfbeff100 irq 40
[    1.289546] ata14: SATA max UDMA/133 irq_stat 0x80400040 irq 40, connection status changed
[    1.638532] ata13: SATA link down (SStatus 0 SControl 370)
[    2.218075] ata14: SATA link up 3.0 Gbps (SStatus 123 SControl 370)
[    2.223478] ata14.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133
[    2.223483] ata14.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    2.228491] ata14.00: configured for UDMA/133

From lspci:

03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
04:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)

/sys/devices/pci0000:00# ls
0000:00:00.0  0000:00:16.0  0000:00:1b.0  0000:00:1c.4  0000:00:1c.6 
0000:00:1d.0  0000:00:1f.0  0000:00:1f.3   pci_bus  uevent
0000:00:02.0  0000:00:1a.0  0000:00:1c.0  0000:00:1c.5  0000:00:1c.7 
0000:00:1e.0  0000:00:1f.2  firmware_node  power

Shouldn't the SiL controller show up here? There are only 0000:00: nodes.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: mapping ataXX.YY to a /dev/sdX

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Thu Jul 08, 2010 at 12:26:27PM +0200, Mikael Abrahamsson wrote:

> It seems the driver doesn't implement that, I can see it for the 
> ICH10R-controller, but not for the SiL-based one this drive is on:
> 
> [    1.289345] ahci 0000:08:00.0: setting latency timer to 64
> [    1.289436] scsi12 : ahci
> [    1.289501] scsi13 : ahci
> [    1.289542] ata13: SATA max UDMA/133 abar m2048@0xfbeff000 port 0xfbeff100 irq 40
> [    1.289546] ata14: SATA max UDMA/133 irq_stat 0x80400040 irq 40, connection status changed
> [    1.638532] ata13: SATA link down (SStatus 0 SControl 370)
> [    2.218075] ata14: SATA link up 3.0 Gbps (SStatus 123 SControl 370)
> [    2.223478] ata14.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133
> [    2.223483] ata14.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
> [    2.228491] ata14.00: configured for UDMA/133
> 
It would look like ata14 is the equivalent of scsi13 then - lsscsi or
"cat /proc/scsi" should show you the drives connected on controller 13
(or look in /sys/class/scsi_disk/13*/device/block).

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: mapping ataXX.YY to a /dev/sdX

[Mikael Abrahamsson]

On Thu, 8 Jul 2010, Robin Hill wrote:

> It would look like ata14 is the equivalent of scsi13 then - lsscsi or 
> "cat /proc/scsi" should show you the drives connected on controller 13 
> (or look in /sys/class/scsi_disk/13*/device/block).

Oki, yes, that's true, but the mapping from scsi13 to sdj isn't really my 
problem, I can find that out in quite a few ways. It's the mapping of 
ata14.00 to scsi13 that I can say is likely (from dmesg), but not certain.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: mapping ataXX.YY to a /dev/sdX

[Janek Kozicki]

Mikael Abrahamsson said:     (by the date of Thu, 8 Jul 2010 13:05:06 +0200 (CEST))

> On Thu, 8 Jul 2010, Robin Hill wrote:
> 
> > It would look like ata14 is the equivalent of scsi13 then - lsscsi or 
> > "cat /proc/scsi" should show you the drives connected on controller 13 
> > (or look in /sys/class/scsi_disk/13*/device/block).
> 
> Oki, yes, that's true, but the mapping from scsi13 to sdj isn't really my 
> problem, I can find that out in quite a few ways. It's the mapping of 
> ata14.00 to scsi13 that I can say is likely (from dmesg), but not certain.

could you make some trial and error tests, while staying safe?

turn off the array. Shut down. Unplug sdj, boot up. See if it is sdj
that disappeared, but do not assemble the array (so that it won't get
corrupted).

-- 
Janek Kozicki                               http://janek.kozicki.pl/  |

Re: mapping ataXX.YY to a /dev/sdX

[Mikael Abrahamsson]

On Thu, 8 Jul 2010, Janek Kozicki wrote:

> could you make some trial and error tests, while staying safe?
>
> turn off the array. Shut down. Unplug sdj, boot up. See if it is sdj
> that disappeared, but do not assemble the array (so that it won't get
> corrupted).

I used smartctl to check that sdj indeed had bad sectors and just failed 
it from the array and then lit it up by dd:ing from it, checked what drive 
it was, and replaced it. When I unplugged it and put in another drive it 
was indeed ata14.

I never really had a huge problem figuring out with high probability which 
drive it was, but I wanted to know if there was a 100% certain way of 
doing it. Seems there is not, am I the only one who is looking for this 
functionality? I would think this is a fairly common problem?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: mapping ataXX.YY to a /dev/sdX

[Brad Campbell]

On 09/07/10 05:53, Mikael Abrahamsson wrote:

> I never really had a huge problem figuring out with high probability
> which drive it was, but I wanted to know if there was a 100% certain way
> of doing it. Seems there is not, am I the only one who is looking for
> this functionality? I would think this is a fairly common problem?

Certainty would be nice, but in practice here I've always found that ataX = sdX+1 and I've relied on 
that mapping to always be constant. I've not yet found it otherwise, but I guess it's possible. I'd 
assume the libata guys should be able to provide a definite comment on that.

I've got no lights on my arrays, so it's even harder to identify which drive is which when you need 
to swap one out live. I've resorted to keeping a log of which serial number is in which physical 
slot, so I can look up the serial number of the failing drive with hdparm and I know I've got the 
right one. Again, it still hinges on the ata-sd mapping being constant. (it also relies on me 
updating the log when I swap a disk)

Brad
-- 
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.

Re: mapping ataXX.YY to a /dev/sdX

[Rudy Zijlstra]

Brad Campbell wrote:
> On 09/07/10 05:53, Mikael Abrahamsson wrote:
>
>> I never really had a huge problem figuring out with high probability
>> which drive it was, but I wanted to know if there was a 100% certain way
>> of doing it. Seems there is not, am I the only one who is looking for
>> this functionality? I would think this is a fairly common problem?
>
> Certainty would be nice, but in practice here I've always found that 
> ataX = sdX+1 and I've relied on that mapping to always be constant. 
> I've not yet found it otherwise, but I guess it's possible. I'd assume 
> the libata guys should be able to provide a definite comment on that.
>
> I've got no lights on my arrays, so it's even harder to identify which 
> drive is which when you need to swap one out live. I've resorted to 
> keeping a log of which serial number is in which physical slot, so I 
> can look up the serial number of the failing drive with hdparm and I 
> know I've got the right one. Again, it still hinges on the ata-sd 
> mapping being constant. (it also relies on me updating the log when I 
> swap a disk)
>
> Brad
Judging from my dmesg and lsscsi on a system with both scsi and SATA, 
ataX translates into scsi X:0:0:0

example dmesg output:
[    3.901035] ata10: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.937046] ata10.00: ATA-7: WDC WD7500AAKS-00RBA0, 30.04G30, max 
UDMA/133
[    3.948794] ata10.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 
31/32)
[    3.969065] ata10.00: configured for UDMA/133
[    3.980847] scsi 10:0:0:0: Direct-Access     ATA      WDC 
WD7500AAKS-0 30.0 PQ: 0 ANSI: 5
[    3.993120] sd 10:0:0:0: [sdf] 1465149168 512-byte hardware sectors: 
(750 GB/698 GiB)
[    4.005586] sd 10:0:0:0: [sdf] Write Protect is off
[    4.017936] sd 10:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[    4.017959] sd 10:0:0:0: [sdf] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

and the lsscsi output:
[0:2:0:0]    disk    LSI      MegaRAID 8344ELP 1.12  /dev/sda
[0:2:1:0]    disk    LSI      MegaRAID 8344ELP 1.12  /dev/sdb
[5:0:1:0]    cd/dvd  MATSHITA DVD-ROM UJDA780  1.50  /dev/sr0
[7:0:0:0]    disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdm
[8:0:0:0]    disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdl
[9:0:0:0]    disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdo
[10:0:0:0]   disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdn
[11:0:0:0]   disk    ATA      SAMSUNG HD103SJ  1AJ1  /dev/sdk
[12:0:0:0]   disk    ATA      Hitachi HDT72101 ST6O  /dev/sdh
[13:0:0:0]   disk    ATA      Hitachi HDT72101 ST6O  /dev/sdi
[14:0:0:0]   disk    ATA      Hitachi HDT72101 ST6O  /dev/sdj



Cheers,


Rudy

Re: mapping ataXX.YY to a /dev/sdX

[Anssi Hannula]

Rudy Zijlstra kirjoitti lauantai, 10. heinäkuuta 2010 10:05:40:
> Judging from my dmesg and lsscsi on a system with both scsi and SATA,
> ataX translates into scsi X:0:0:0

AFAIK this is only because you have a real SCSI occupying scsi0. On systems 
with only ATA, ataN is scsi(N-1).

I guess it really depends on the load order of ATA, SCSI and USB storage 
device drivers.

This should probably be changed somehow.. either make ataXX binding available 
somewhere or use some other known identifier instead of ataXX.

> example dmesg output:
> [    3.901035] ata10: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    3.937046] ata10.00: ATA-7: WDC WD7500AAKS-00RBA0, 30.04G30, max
> UDMA/133
> [    3.948794] ata10.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth
> 31/32)
> [    3.969065] ata10.00: configured for UDMA/133
> [    3.980847] scsi 10:0:0:0: Direct-Access     ATA      WDC
> WD7500AAKS-0 30.0 PQ: 0 ANSI: 5
> [    3.993120] sd 10:0:0:0: [sdf] 1465149168 512-byte hardware sectors:
> (750 GB/698 GiB)
> [    4.005586] sd 10:0:0:0: [sdf] Write Protect is off
> [    4.017936] sd 10:0:0:0: [sdf] Mode Sense: 00 3a 00 00
> [    4.017959] sd 10:0:0:0: [sdf] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> 
> and the lsscsi output:
> [0:2:0:0]    disk    LSI      MegaRAID 8344ELP 1.12  /dev/sda
> [0:2:1:0]    disk    LSI      MegaRAID 8344ELP 1.12  /dev/sdb
> [5:0:1:0]    cd/dvd  MATSHITA DVD-ROM UJDA780  1.50  /dev/sr0
> [7:0:0:0]    disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdm
> [8:0:0:0]    disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdl
> [9:0:0:0]    disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdo
> [10:0:0:0]   disk    ATA      SAMSUNG HD154UI  1AG0  /dev/sdn
> [11:0:0:0]   disk    ATA      SAMSUNG HD103SJ  1AJ1  /dev/sdk
> [12:0:0:0]   disk    ATA      Hitachi HDT72101 ST6O  /dev/sdh
> [13:0:0:0]   disk    ATA      Hitachi HDT72101 ST6O  /dev/sdi
> [14:0:0:0]   disk    ATA      Hitachi HDT72101 ST6O  /dev/sdj

-- 
Anssi Hannula
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mapping ataXX.YY to a /dev/sdX

[Jeff Garzik]

On 07/10/2010 03:05 AM, Rudy Zijlstra wrote:
> Judging from my dmesg and lsscsi on a system with both scsi and SATA,
> ataX translates into scsi X:0:0:0


There is no translation.

It is random, based on driver load order.

	Jeff

Re: mapping ataXX.YY to a /dev/sdX

[Rudy Zijlstra]

Jeff Garzik wrote:
> On 07/10/2010 03:05 AM, Rudy Zijlstra wrote:
>> Judging from my dmesg and lsscsi on a system with both scsi and SATA,
>> ataX translates into scsi X:0:0:0
>
>
> There is no translation.
>
> It is random, based on driver load order.
This then begs the question whether it can be dependingly derived from 
dmesg messages. Like messages

[    2.268315] ata7.00: configured for UDMA/133
[    2.277452] scsi 7:0:0:0: Direct-Access     ATA      WDC WD7500AAKS-0 
30.0 PQ: 0 ANSI: 5

always following each other, thus making identification possible.


Cheers,


Rudy

Re: mapping ataXX.YY to a /dev/sdX

[Jérôme Poulin]

I find it rather confusing in my log, and there are situation when you
hotplug the disk which does not make it show up right after the ataX
line, also if the logs overflow, then you can't know anyway. (I know
there's syslog too)

There doesn't seem to be any mapping in /sys I though lshw would show
it but it isn't.

[    1.378503] loop: module loaded
[    1.382075] ata_piix 0000:00:1f.2: version 2.13
[    1.382100] ata_piix 0000:00:1f.2: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    1.389566] ata_piix 0000:00:1f.2: MAP [ IDE IDE P0 P1 ]
[    1.395265] ata_piix 0000:00:1f.2: setting latency timer to 64
[    1.395349] scsi0 : ata_piix
[    1.398516] scsi1 : ata_piix
[    1.401647] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xfc00 irq 14
[    1.408880] ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfc08 irq 15
[    1.416308] sata_mv 0000:01:00.0: version 1.28
[    1.420999] sata_mv 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    1.428614] sata_mv 0000:01:00.0: Gen-IIE 32 slots 4 ports ? mode
IRQ via INTx
[    1.436133] sata_mv 0000:01:00.0: setting latency timer to 64
[    1.436591] scsi2 : sata_mv
[    1.436751] scsi3 : sata_mv
[    1.436889] scsi4 : sata_mv
[    1.437024] scsi5 : sata_mv
[    1.437141] ata3: SATA max UDMA/133 mmio m1048576@0xfc800000 port
0xfc822000 irq 16
[    1.437146] ata4: SATA max UDMA/133 mmio m1048576@0xfc800000 port
0xfc824000 irq 16
[    1.437150] ata5: SATA max UDMA/133 mmio m1048576@0xfc800000 port
0xfc826000 irq 16
[    1.437154] ata6: SATA max UDMA/133 mmio m1048576@0xfc800000 port
0xfc828000 irq 16
[    1.442237] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k6-NAPI
[    1.442241] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    1.442278] e1000 0000:03:03.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
[    1.506175] ata1.00: ATAPI: HL-DT-ST DVDRAM GSA-4167B, DL12, max UDMA/33
[    1.506433] ata2.01: ATA-8: OCZ-ONYX, 1.6, max UDMA/133
[    1.506437] ata2.01: 62533296 sectors, multi 1: LBA48 NCQ (depth 0/32)
[    1.546986] ata2.01: configured for UDMA/133
[    1.559278] ata1.00: configured for UDMA/33
[    1.576801] scsi 0:0:0:0: CD-ROM            HL-DT-ST DVDRAM
GSA-4167B DL12 PQ: 0 ANSI: 5
[    1.605506] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw
xa/form2 cdda tray
[    1.621572] Uniform CD-ROM driver Revision: 3.20
[    1.635283] sr 0:0:0:0: Attached scsi CD-ROM sr0
[    1.635478] sr 0:0:0:0: Attached scsi generic sg0 type 5
[    1.649870] scsi 1:0:1:0: Direct-Access     ATA      OCZ-ONYX
  1.6  PQ: 0 ANSI: 5
[    1.667596] sd 1:0:1:0: [sda] 62533296 512-byte logical blocks:
(32.0 GB/29.8 GiB)
[    1.667672] sd 1:0:1:0: Attached scsi generic sg1 type 0
[    1.699875] sd 1:0:1:0: [sda] Write Protect is off
[    1.714493] sd 1:0:1:0: [sda] Mode Sense: 00 3a 00 00
[    1.714527] sd 1:0:1:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[    1.734022]  sda: sda1 sda2 sda3 sda4
[    1.758945] e1000 0000:03:03.0: eth0: (PCI:66MHz:32-bit)
[    1.759032] sd 1:0:1:0: [sda] Attached SCSI disk
[    1.790414] e1000 0000:03:03.0: eth0: 00:30:48:58:1d:82
[    1.806615] e1000 0000:03:03.0: eth0: Intel(R) PRO/1000 Network Connection
[    1.824685] e1000 0000:03:04.0: PCI INT A -> GSI 27 (level, low) -> IRQ 27
[    1.946696] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    2.003382] ata3.00: ATA-8: ST3320613AS, CC2H, max UDMA/133
[    2.021065] ata3.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.100074] ata3.00: configured for UDMA/133
[    2.116753] scsi 2:0:0:0: Direct-Access     ATA      ST3320613AS
  CC2H PQ: 0 ANSI: 5


On Sat, Jul 10, 2010 at 7:49 PM, Rudy Zijlstra
<rudy@grumpydevil.homelinux.org> wrote:
> Jeff Garzik wrote:
>>
>> On 07/10/2010 03:05 AM, Rudy Zijlstra wrote:
>>>
>>> Judging from my dmesg and lsscsi on a system with both scsi and SATA,
>>> ataX translates into scsi X:0:0:0
>>
>>
>> There is no translation.
>>
>> It is random, based on driver load order.
>
> This then begs the question whether it can be dependingly derived from dmesg
> messages. Like messages
>
> [    2.268315] ata7.00: configured for UDMA/133
> [    2.277452] scsi 7:0:0:0: Direct-Access     ATA      WDC WD7500AAKS-0
> 30.0 PQ: 0 ANSI: 5
>
> always following each other, thus making identification possible.
>
>
> Cheers,
>
>
> Rudy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mapping ataXX.YY to a /dev/sdX

[Jim Paris]

Jérôme Poulin wrote:
> On Sat, Jul 10, 2010 at 7:49 PM, Rudy Zijlstra
> <rudy@grumpydevil.homelinux.org> wrote:
> > Jeff Garzik wrote:
> >>
> >> On 07/10/2010 03:05 AM, Rudy Zijlstra wrote:
> >>>
> >>> Judging from my dmesg and lsscsi on a system with both scsi and SATA,
> >>> ataX translates into scsi X:0:0:0
> >>
> >>
> >> There is no translation.
> >>
> >> It is random, based on driver load order.
> >
> > This then begs the question whether it can be dependingly derived from dmesg
> > messages. Like messages
> >
> > [    2.268315] ata7.00: configured for UDMA/133
> > [    2.277452] scsi 7:0:0:0: Direct-Access     ATA      WDC WD7500AAKS-0
> > 30.0 PQ: 0 ANSI: 5
> >
> > always following each other, thus making identification possible.
>
> I find it rather confusing in my log, and there are situation when you
> hotplug the disk which does not make it show up right after the ataX
> line, also if the logs overflow, then you can't know anyway. (I know
> there's syslog too)
> 
> There doesn't seem to be any mapping in /sys I though lshw would show
> it but it isn't.

For a scsi_host driven by libata, the number in /sys/class/scsi_host/host?/unique_id
should match the ataX value.  You can check /sys/class/scsi_host/host?/proc_name
to see the driver for a particular scsi_host.

-jim
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html