Comment puis-je faire reconnaître à Linux un nouveau disque SATA / dev / sda dans lequel j'ai échangé à chaud sans redémarrer?
L'échange à chaud d'un disque SATA/dev/sda en panne a bien fonctionné, mais quand je suis allé échanger un nouveau disque, il n'a pas été reconnu:
[root@fs-2 ~]# tail -18 /var/log/messages
May 5 16:54:35 fs-2 kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
May 5 16:54:35 fs-2 kernel: ata1: SError: { PHYRdyChg CommWake }
May 5 16:54:40 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:54:45 fs-2 kernel: ata1: device not ready (errno=-16), forcing hardreset
May 5 16:54:45 fs-2 kernel: ata1: soft resetting link
May 5 16:54:50 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:54:55 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:54:55 fs-2 kernel: ata1: soft resetting link
May 5 16:55:00 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:55:05 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:55:05 fs-2 kernel: ata1: soft resetting link
May 5 16:55:10 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:55:40 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:55:40 fs-2 kernel: ata1: limiting SATA link speed to 1.5 Gbps
May 5 16:55:40 fs-2 kernel: ata1: soft resetting link
May 5 16:55:45 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:55:45 fs-2 kernel: ata1: reset failed, giving up
May 5 16:55:45 fs-2 kernel: ata1: EH complete
J'ai essayé quelques choses pour que le serveur trouve le nouveau/dev/sda, comme rescan-scsi-bus.sh mais cela n'a pas fonctionné:
[root@fs-2 ~]# echo "---" > /sys/class/scsi_Host/host0/scan
-bash: echo: write error: Invalid argument
[root@fs-2 ~]#
[root@fs-2 ~]# /root/rescan-scsi-bus.sh -l
[snip]
0 new device(s) found.
0 device(s) removed.
[root@fs-2 ~]#
[root@fs-2 ~]# ls /dev/sda
ls: /dev/sda: No such file or directory
J'ai fini par redémarrer le serveur./dev/sda a été reconnu, j'ai corrigé le RAID logiciel et tout va bien maintenant. Mais pour la prochaine fois, comment puis-je faire reconnaître à Linux un nouveau disque SATA que j'ai échangé à chaud sans redémarrer?
Le système d'exploitation en question est RHEL5.3:
[root@fs-2 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Le disque dur est un Seagate Barracuda ES.2 SATA 3.0-Gb/s 500-GB, modèle ST3500320NS.
Voici la sortie lscpi:
[root@fs-2 ~]# lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
04:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
04:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
Mise à jour : Dans peut-être une douzaine de cas, nous avons été obligés de redémarrer les serveurs car le remplacement à chaud n'a pas "juste fonctionné". Merci pour les réponses à approfondir le contrôleur SATA. J'ai inclus la sortie lspci pour le système problématique ci-dessus (nom d'hôte: fs-2). Je pourrais toujours utiliser de l'aide pour comprendre ce qui n'est pas pris en charge au niveau matériel en termes de remplacement à chaud pour ce système. Veuillez me faire savoir quelles autres sorties en plus de lspci pourraient être utiles.
La bonne nouvelle est que le remplacement à chaud "vient de fonctionner" aujourd'hui sur l'un de nos serveurs (nom d'hôte: www-1), ce qui est très rare pour nous. Voici la sortie lspci:
[root@www-1 ~]# lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:19.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
04:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
04:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
09:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 04)
Si votre contrôleur SATA prend en charge le remplacement à chaud, il devrait "simplement fonctionner (tm)".
Pour forcer une nouvelle analyse sur un BUS SCSI (chaque port SATA apparaît comme un BUS SCSI) et trouver de nouveaux disques, vous utiliserez:
echo "0 0 0" >/sys/class/scsi_Host/host<n>/scan
Sur ce qui précède, <n> est le numéro de BUS.
echo "- - -" >/sys/class/scsi_Host/host<n>/scan
^ ^
\_\_______ note spaces between the dashes.
Lorsqu'un disque est tombé en panne dans certaines circonstances, Linux ne réalisera pas que vous l'avez réellement retiré physiquement de la baie. Si vous avez ce problème (comme je l'ai fait ce matin), vous pouvez faire ce qui suit:
echo 1 > /sys/block/<devnode>/device/delete
Par exemple. dans mon cas/dev/sda avait échoué et je ne voulais pas redémarrer le serveur, alors j'ai fait:
echo 1 > /sys/block/sda/device/delete
Après cela, le nouveau lecteur (qui avait déjà été physiquement ajouté) était immédiatement visible.
S'il n'est pas visible à ce stade, vous pouvez également le faire pour forcer une nouvelle analyse:
echo "- – -" > /sys/class/scsi_Host/host<n>/scan
Ce "- - -" est respectivement des caractères génériques pour le canal, l'id et le LUN, vous pouvez donc limiter l'analyse à un sous-ensemble si vous le souhaitez en spécifiant des nombres à la place.
Avant de commencer, vous pouvez également:
readlink /sys/block/<devnode>
Ce qui vous montrera le chemin d'accès avec le bon numéro d'hôte pour archiver/proc/scsi/scsi pour la disparition après la suppression.
Que diriez-vous de cela (semble fonctionner dans Ubuntu):
Sonde partielle Sudo
Je ne peux pas croire que personne n'ait encore mentionné AHCI ... votre contrôleur SATA doit être en mode AHCI pour permettre le remplacement à chaud. Vérifiez cela en regardant le pilote que vous utilisez:
root@peter:~ # find /sys -name sdk
/sys/devices/pci0000:00/0000:00:11.0/ata5/Host4/target4:0:0/4:0:0:0/block /sdk
/sys/block/sdk
/sys/class/block/sdk
root@peter:~ # readlink /sys/devices/pci0000:00/0000:00:11.0/driver
../../../bus/pci/drivers/ahci
root@peter:~ # lspci -k | less
[... big long output... search for ahci or your pci address, or use the awk below ...]
root@peter:~ # lspci -k | awk '$1 == "00:11.0" {x=1}; x && /in use/ {print $0; exit}'
Kernel driver in use: ahci
Voyez comment ça dit "ahci" là-bas.
Si ce n'est pas le cas, activez-le simplement dans votre BIOS. De plus, certains BIOS, en particulier sur les serveurs ou UEFI, ont un paramètre "Hot Swap = activé/désactivé" par disque que vous devez également activer s'il existe.
Voici pourquoi j'avais besoin de redémarrer l'ordinateur ...
Je viens d'échanger à chaud mon/dev/sdc. J'ai utilisé scsiadd -r 3 0 0 pour éteindre l'ancien disque avant de le retirer. Ensuite, après l'installation du nouveau disque, le nouveau disque n'apparaissait pas sous la forme/dev/sdc mais plutôt sous la forme/dev/sdd. Après un redémarrage, le disque réapparaîtrait à nouveau sous le nom/dev/sdc.
Il semble donc que le hotswap fonctionne. Ok, il se peut que le/dev/sd * ne soit plus le même.
Serait-ce une réponse à votre problème?
Le contrôleur Fusion-MPT SAS que vous avez est un contrôleur RAID bas de gamme. Si vous ne l’utilisez pas pour le RAID, il peut tout de même fournir une couche inutile d’obstruction/abstraction.
Vous devrez peut-être piquer le contrôleur RAID avec mpt-status ou lsiutil pour qu'il analyse réellement le bus.
http://hwraid.le-vert.net/wiki/LSIFusionMPT a une belle documentation, mais je ne peux pas dire que je l'ai vérifiée.
Dans certains cas, le remplacement à chaud peut devoir être activé sur le BIOS de la carte mère et/ou du contrôleur SATA. Cela dépend complètement de la marque et du modèle des deux, mais si vous avez des contrôleurs SATA intégrés qui devraient prendre en charge le hotswap, cela vaut la peine de passer au peigne fin le BIOS de la carte mère. Les cartes SATA peuvent ou non avoir leurs propres paramètres BIOS, ce n'est pas le cas de nombreuses cartes bas de gamme, mais généralement les cartes de qualité serveur.
Si je me souviens bien, j'ai eu besoin de cela avec un certain nombre de cartes mères Gigabyte, et peut-être d'autres marques. J'en avais besoin pour qu'un plateau SATA remplaçable à chaud fonctionne; avec la fonctionnalité désactivée, la suppression du lecteur n'a pas causé de problèmes, mais un nouveau lecteur ne s'enregistrerait pas avant le redémarrage. L'activation du paramètre a fonctionné comme prévu, les disques qui ont été placés dans le tiroir ont été immédiatement tournés et disponibles pour le système d'exploitation.
Mon DVD sur ma machine Fedora 16 est connecté à une interface SATA. Il était verrouillé et ne pouvait ni s'ouvrir ni se fermer. L'exécution de partprobe en tant que root a permis à mon cdrom/DVD de fonctionner à nouveau. Je pense que cela aidera sur une autre machine où j'ai un problème de remplacement à chaud occasionnel. Merci!
Je sais que cette question est ancienne, mais j'ai eu un certain succès que je n'ai pas vu rapporté ailleurs. J'ai eu des problèmes similaires sur un Dell Precision 380 aujourd'hui. Finalement, cela a fonctionné en faisant une combinaison des éléments suivants:
echo "- - -" > /sys/class/scsi_Host/host2/scan
echo 1 > /sys/class/scsi_device/2:0:0:0/device/reset
echo 1 > /sys/devices/pci0000:00/0000:00:1f.2/rescan
echo 1 > /sys/devices/pci0000:00/0000:00:1f.2/reset
AVERTISSEMENT: Cela peut également perturber d'autres périphériques ATA du système. Si vous avez monté des systèmes de fichiers sur ces périphériques, cela risque de mal se terminer. Ma situation s'en fichait, mais la vôtre le pouvait.
Je ne sais pas exactement laquelle des commandes ci-dessus est nécessaire et dans quel ordre. Certaines commandes peuvent devoir être répétées. Si je devais deviner, je dirais faire dans l'ordre indiqué ci-dessus, puis une autre analyse scsi_Host à la fin. J'en ai fait pas mal plus dans mes explorations.
La première commande (scsi_Host scan) indique à la couche intermédiaire SCSI de rechercher dans tous les bus les périphériques nouveaux/modifiés. La deuxième commande tente de réinitialiser la cible SCSI (périphérique de disque). Les deux derniers fonctionnent avec le pilote du contrôleur AHCI lui-même.
J'ai trouvé les articles en question principalement par un examen détaillé et une expérimentation audacieuse.
Vous pouvez faire correspondre les nœuds scsi_device à la marque et au modèle du périphérique (en utilisant grep pour imprimer les noms de fichiers devant le contenu):
grep . /sys/class/scsi_device/*/device/model
Le premier chiffre de l'ID de périphérique SCSI doit être le numéro scsi_Host. Vous pouvez ensuite faire correspondre les nœuds scsi_Host à leurs nœuds de périphériques avec:
ls -l /sys/class/scsi_Host
Je soupçonne que je n'aurai jamais l'occasion de raffiner davantage, alors je voulais partager cette information dans l'espoir de rapprocher les autres. Si j'obtiens plus d'informations, je modifierai cette réponse pour y réfléchir.
J'espère que cela t'aides.
Pour que le branchement à chaud fonctionne, vous devez avoir le module acpiphp chargé.
[root@example ~]# modprobe acpiphp
évidemment, si vous voulez que cela fonctionne au démarrage, vous devrez configurer cela pour qu'il soit chargé au démarrage - une façon consiste à créer/modifier /etc/rc.modules (qui est appelé par rc.sysinit) et ajouter la ligne:
modprobe acpiphp
rappelez-vous si vous créez ce fichier dans chmod + x, comme il est appelé de cette manière.