Puede encontrar el dispositivo / dev / sdY correspondiente atravesando el /sys
árbol:
$ find /sys/devices | grep '/ata[0-9]\+/.*/block/s[^/]\+$' \
| sed 's@^.\+/\(ata[0-9]\+\)/.\+/block/\(.\+\)$@\1 => /dev/\2@'
Con un /sys
recorrido más eficiente (cf. lsata.sh ):
$ echo /sys/class/ata_port/ata*/../../host*/target*/*/block/s* | tr ' ' '\n' \
| awk -F/ '{printf("%s => /dev/%s\n", $5, $NF)}'
Ejemplo de salida de un sistema de 2 discos:
ata1 => /dev/sda
ata2 => /dev/sdb
Luego, para identificar de manera confiable el hardware real, debe asignar / dev / sdY al número de serie, por ejemplo:
$ ls /dev/disk/by-id -l | grep 'ata.*sd[a-zA-Z]$'
lssci
La lssci
utilidad también se puede utilizar para derivar la asignación:
$ lsscsi | sed 's@^\[\([^:]\+\).\+\(/dev/.\+\)$@\1,\2@' \
| awk -F, '{ printf("ata%d => %s\n", $1+1, $2) }'
Tenga en cuenta que la enumeración lsscsi relevante comienza desde 0 mientras que la enumeración ata comienza desde 0.
Syslog
Si nada más funciona, uno puede mirar el syslog / journal para derivar el mapeo.
Los /dev/sdY
dispositivos se crean en el mismo orden en que se enumeran los identificadores ataX kern.log
mientras se ignoran los dispositivos sin disco (ATAPI) y los enlaces no conectados.
Por lo tanto, el siguiente comando muestra la asignación:
$ grep '^May 28 2' /var/log/kern.log.0 | \
grep 'ata[0-9]\+.[0-9][0-9]: ATA-' | \
sed 's/^.*\] ata//' | \
sort -n | sed 's/:.*//' | \
awk ' { a="ata" $1; printf("%10s is /dev/sd%c\n", a, 96+NR); }'
ata1.00 is /dev/sda
ata3.00 is /dev/sdb
ata5.00 is /dev/sdc
ata7.00 is /dev/sdd
ata8.00 is /dev/sde
ata10.00 is /dev/sdf
(Tenga en cuenta que ata4 no se muestra porque los mensajes de registro anteriores son de otro sistema).
Estoy usando /var/log/kern.log.0
y no /var/log/kern.log
porque los mensajes de arranque ya están rotados. Estoy ansioso May 28 2
porque este fue el último tiempo de arranque y quiero ignorar los mensajes anteriores.
Para verificar la asignación, puede hacer algunas comprobaciones mirando la salida de:
$ grep '^May 28 2' /var/log/kern.log.0 | \
grep 'ata[0-9]\+.[0-9][0-9]: ATA-'
May 28 20:43:26 hn kernel: [ 1.260488] ata1.00: ATA-7: SAMSUNG SV0802N, max UDMA/100
May 28 20:43:26 hn kernel: [ 1.676400] ata5.00: ATA-5: ST380021A, 3.19, max UDMA/10
[..]
Y puede comparar esta salida con la hdparm
salida, por ejemplo:
$ hdparm -i /dev/sda
/dev/sda:
Model=SAMSUNG SV0802N [..]
(usando Kernel 2.6.32-31)
Aquí está mi versión, modificada desde arriba. Como no sé la fecha exacta en que se inició el sistema (para probar esto fue hace 27 días), y no sé qué kern.log contiene los datos que necesito (algunos pueden estar
gzipped
en mi sistema), utilizouptime
ydate
para calcular una fecha aproximada de inicio del sistema (al día, de todos modos), luego usezgrep
para buscar en todos los archivos kern.log disponibles.También modifiqué ligeramente la segunda
grep
declaración, ya que ahora también mostrará una unidad de CD / DVD ATAPI, así como unidades ATA- *.Todavía podría usar refinamiento (es decir, si el tiempo de actividad del sistema es mayor a un año), pero debería funcionar bien por ahora.
fuente
Acabo de tener este mismo problema y encontré otra solución que podría gustarle.
La herramienta lsscsi enumera los dispositivos SCSI (o hosts) y sus atributos.
Con lsscsi se obtiene el nombre ata y el nombre del dispositivo.
Se ve como esto:
En Ubuntu uno puede instalar lsscsi simplemente con
fuente
ataX
mapa a qué parte de lalsscsi
salida?lsscsi | sed 's@^\[\([^:]\+\).\+\(/dev/.\+\)$@\1,\2@' | awk -F, '{ printf("ata%d => %s\n", $1+1, $2) }'
/sys/devices
sinlsscsi
.Ninguna de las respuestas anteriores funcionó para mí, y el enfoque lsscsi en realidad arrojó la respuesta incorrecta, debido a las discrepancias entre los números de bus SCSI y los números ATA. En un sistema de 21 discos, tuve muchos informes de syslog sobre problemas con ATA18 (violaciones de HSM). ¿Qué disco estaba causando estos errores? Algunos eran unidades USB, lo que hacía las cosas considerablemente más confusas. Necesitaba un recuento de cómo todas y cada una de las unidades SCSI están conectadas al sistema, y escribí el siguiente script que produce listados tabulares para todos los discos SCSI (/ dev / s [dr]?) Independientemente de si es ATA o USB.
Luego, con todas las unidades de disco totalmente explicadas, me sorprendió ver que mis errores ATA no tenían nada que ver con ninguna de mis unidades de disco. Había estado haciendo la pregunta equivocada, y creo que otros podrían caer fácilmente en la misma trampa, por eso lo menciono aquí. Luego utilicé un segundo enfoque que identificaba el hardware que generaba los mensajes de violación de HSM, también detallado en la documentación que aparece en el script a continuación.
fuente