Étant donné une exception ATA du kernel, comment déterminer quel disque physique est affecté?

Je me suis réveillé ce matin à un email de notification avec quelques inputs de journal système plutôt dérangeantes.

Dec 2 04:27:01 yeono kernel: [459438.816058] ata2.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen Dec 2 04:27:01 yeono kernel: [459438.816071] ata2.00: failed command: WRITE FPDMA QUEUED Dec 2 04:27:01 yeono kernel: [459438.816085] ata2.00: cmd 61/08:00:70:0d:ca/00:00:08:00:00/40 tag 0 ncq 4096 out Dec 2 04:27:01 yeono kernel: [459438.816088] res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout) Dec 2 04:27:01 yeono kernel: [459438.816095] ata2.00: status: { DRDY } (the above five lines were repeated a few times at a short interval) Dec 2 04:27:01 yeono kernel: [459438.816181] ata2: hard resetting link Dec 2 04:27:02 yeono kernel: [459439.920055] ata2: SATA link down (SStatus 0 SControl 300) Dec 2 04:27:02 yeono kernel: [459439.932977] ata2: hard resetting link Dec 2 04:27:09 yeono kernel: [459446.100050] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Dec 2 04:27:09 yeono kernel: [459446.314509] ata2.00: configured for UDMA/133 Dec 2 04:27:09 yeono kernel: [459446.328037] ata2.00: device reported invalid CHS sector 0 ("reported invalid CHS sector 0" repeated a few times at a short interval) 

Je fais toutes les sauvegardes nocturnes de l'set de mon système sur un lecteur externe (connecté par USB), et ce qui précède est arrivé au milieu de cette exécution de sauvegarde. (La sauvegarde commence à 04:00 via cron, et la fin de session de ce soir juste avant 04:56). Le process de sauvegarde lui-même prétend avoir terminé sans aucune erreur.

Il y a deux disques SATA connectés en interne et deux lecteurs connectés en externe (USB) sur mon système; l'un des lecteurs externes est actuellement inactif. Je ne me souviens pas du haut de ma tête quels ports SATA physiques sont utilisés pour lequel des disques internes.

Lorsque Google a trouvé la question AskUbuntu Est-ce que cet échec de lecteur ou quelque chose d'autre? ce qui indique qu'une erreur très similaire s'est produite après que 8 à 10 Go aient été copiés sur un lecteur, mais le mode de défaillance réel était différent lorsque le lecteur passait en mode lecture seule. La seule vraie similitude est que j'ai ajouté de l'ordre de 7-8 Go ​​de données à mon stockage principal la nuit dernière, ce qui aurait été sauvegardé au moment où l'erreur s'est produite.

smartd ne signale rien sur l'un des lecteurs internes. Malheureusement, smartctl ne parle pas la langue du pont USB du lecteur de sauvegarde externe, et se plaint simplement d' Unknown USB bridge [0x0bc2:0x3320 (0x100)] . Googler pour cette erreur spécifique était nettement inutile.

Mon stockage de données principal ainsi que la sauvegarde est sur ZFS et zpool status signale 0 erreurs et aucune erreur de données connues. Néanless, j'ai initié un gommage complet sur les lecteurs internes et externes. Il est actuellement prévu de terminer dans environ six heures pour le lecteur interne (pool de stockage principal) et 13-14 heures pour le lecteur de sauvegarde.

Il semble que la prochaine étape devrait être de déterminer quel lecteur avait des problèmes, et éventuellement le replace. La partie ata2.00 me dit probablement quel lecteur avait des problèmes, mais comment puis-je mapper cet identifiant sur un disque physique?

J'ai écrit un doublure basée sur la réponse de Tobi Hahn.

Par exemple, vous voulez savoir quel périphérique représente ata3:

 ata=3; ls -l /sys/block/sd* | grep $(grep $ata /sys/class/scsi_host/host*/unique_id | awk -F'/' '{print $5}') 

Cela produira quelque chose comme ça

 lrwxrwxrwx 1 root root 0 Jan 15 15:30 /sys/block/sde -> ../devices/pci0000:00/0000:00:1f.5/host2/target2:0:0/2:0:0:0/block/sde 

Il s'avère que faire la cartographie était plus facile que je ne l'ai réalisé.

dmesg | grep ata2 | head dmesg | grep ata2 | head donne le mappage du kernel du kernel pendant le process de démarrage. Ou vous pouvez juste aller pour ata2.00 tout de suite.

 [ 2.448300] ata2: SATA max UDMA/133 abar m1024@0xfeb0b000 port 0xfeb0b180 irq 19 [ 2.940139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.942143] ata2.00: ATA-8: ST31000340NS, SN05, max UDMA/133 [ 2.942149] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 2.944573] ata2.00: configured for UDMA/133 (and some stuff I'd rather never have to see about drive errors) 

Comme vous pouvez le voir, l'une de ces lignes contient mon numéro de model de lecteur ( ST31000340NS ) que je peux ensuite utiliser pour mapper dans un file /dev :

 $ readlink /dev/disk/by-id/*ST31000340NS* | head -n1 ../../sda 

Utilisez cette command:

 ls -l /sys/block/sd* | sed 's/.*\(sd.*\) -.*\(ata.*\)\/h.*/\2 => \1/' 

Sur mon système, cela produit la sortie:

 ata1 => sda ata2 => sdb ata3 => sdc ata4 => sdd ata7 => sde ata8 => sdf 

Cela fonctionnera même si tous les disques ont le même model de lecteur (entre ces 6 disques il n'y a que deux templates différents). Notez que cela dépend du nom de sysfs et fonctionne dans mon kernel 3.10.17. Je sais à un certain moment dans le passé ce n'était pas propre pour récupérer les cartographies, mais je ne suis pas sûr de ce que la première version du kernel cela fonctionnera.

Si cela ne fonctionne pas pour vous, consultez ce lien pour une façon plus détournée de déterminer les mappages: http://www.miriup.de/index.php?option=com_content&view=article&id=84:mapping-linux-kernel- ata-erreurs-à-un-périphérique & catid = 8: linux & Itemid = 25

Voici un onliner pour comprendre tous les périphériques SD sd*

 LC_ALL=C ls -l /sys/block/sd* | perl -npe 's#^.*?block/(sd[^/ ]+).*?/pci0000:00/0000:([^/]+/(?:ata[0-9]+|usb[0-9]+/[^/]+/[^/]+|[0-9:.]+/[^/]+/[^/]+)).*#$1 = $2#' 

Pour moi, la sortie ressemble

 sda = 00:01.0/0000:01:00.0/host0/port-0:0 sdb = 00:01.0/0000:01:00.0/host0/port-0:1 sdc = 00:01.0/0000:01:00.0/host0/port-0:2 sdd = 00:01.0/0000:01:00.0/host0/port-0:3 sde = 00:1d.0/usb2/2-1/2-1.5 sdf = 00:1f.2/ata3 sdg = 00:1f.2/ata4 sdh = 00:1f.2/ata6 

La sortie devrait être assez lisible et les périphériques PCI Express et les périphériques USB obtiennent quelque chose d'aussi sain. Vous pouvez ensuite utiliser le début de l'appareil pour déterminer la connection matérielle réelle. Par exemple, dans l'exemple ci-dessus, 01:00.0 est la carte PCI Express intel SSD 910 avec quatre périphériques secondaires SSD de 200 Go. Le lspci -nn | grep -F 01:00.0 lspci -nn | grep -F 01:00.0 sortie pour le même matériel est

 01:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) 

Le kernel pense donc que sdasdd est attaché au controller LSI Logic PCI-Express SAS-2. Malheureusement, il ne semble pas y avoir de moyen simple de "savoir" que ce périphérique est vraiment la carte Intel SSD 910 PCI Express.