Comment faire en sorte que Linux reconnaisse un nouveau disque SATA / dev / sda dans lequel je permute à chaud sans redémarrer?

Échanger à chaud un disque SATA / dev / sda en panne a bien fonctionné, mais lorsque je suis allé échanger un nouveau disque, il n'était pas 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é plusieurs choses pour que le serveur trouve le nouveau / dev / sda, tel que 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 logiciel RAID, et tout va bien maintenant. Mais pour la prochaine fois, comment puis-je faire en sorte que Linux reconnaisse un nouveau disque SATA dans lequel j'ai été remplacé à chaud sans redémarrage?

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 Go / s 500 Go, 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é forcés de redémarrer des serveurs car l'échange à chaud ne "fonctionnait pas". Merci pour les réponses à regarder plus dans 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 un peu d’aide pour comprendre ce qui n’est pas pris en charge au niveau matériel en termes d’échange à chaud pour ce système. S'il vous plaît laissez-moi savoir ce que la sortie autre que lspci pourrait être utile.

La bonne nouvelle est que l'échange à 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 de 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 l’échange à chaud, il devrait "fonctionner correctement (tm)".

Pour forcer une nouvelle analyse sur un bus SCSI (chaque port SATA apparaît en tant que bus SCSI) et rechercher 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.

Dans certaines circonstances, lorsqu'un lecteur a échoué, Linux ne réalisera pas que vous l'avez réellement extrait physiquement de la matrice. Si vous avez ce problème (comme ce matin), vous pouvez procéder comme suit:

echo 1 > /sys/block/<devnode>/device/delete

Par exemple, dans mon cas, / dev / sda a échoué et je ne voulais pas redémarrer le serveur, alors j'ai:

echo 1 > /sys/block/sda/device/delete

Après cela, le nouveau disque (qui avait déjà été physiquement ajouté) était immédiatement visible.

Si ce 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 "- - -" correspond à des caractères génériques pour channel, id et LUN respectivement. 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 avec le bon numéro d’hôte pour vérifier dans / proc / scsi / scsi la disparition après le retrait.

Que diriez-vous de cela (semble fonctionner dans Ubuntu):

sudo partprobe

Je n'arrive 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 ceci 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, certaines BIOS, en particulier sur les serveurs ou UEFI, ont un paramètre "Hot Swap = enabled / disabled" par disque que vous devez également activer s'il existe.

Voici pourquoi j'avais besoin de redémarrer l'ordinateur ...

Je viens de permuter à 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 / dev / sdd. Après un redémarrage, le disque réapparaîtra sous le nom / dev / sdc.

Il semble donc que le hot-back fonctionne bien, c’est peut-être simplement que le fichier / dev / sd * n’est plus le même.

Cela pourrait-il être une réponse à votre problème?

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 qu'utilisateur root a permis à mon CD / DVD de fonctionner à nouveau. Je pense que cela aidera sur la machine à anthères, où j’ai parfois le problème de la permutation à chaud. Merci!

Le contrôleur SAS Fusion-MPT dont vous disposez est un contrôleur RAID bas de gamme. Si vous ne l'utilisez pas pour le RAID, il se peut qu'il fournisse encore une couche inutile d'obstruction / abstraction.

Vous devrez peut-être examiner le contrôleur RAID avec mpt-status ou lsiutil pour le faire analyser le bus.

http://hwraid.le-vert.net/wiki/LSIFusionMPT a une belle quantité de documentation, mais je ne peux pas dire que je l'ai vérifiée.

Dans certains cas, il peut être nécessaire d'activer le remplacement à chaud dans 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 l’échange à chaud, cela vaut la peine de parcourir le BIOS de la carte mère. Les cartes SATA peuvent ou non avoir leurs propres paramètres BIOS, contrairement à beaucoup de cartes bas de gamme, mais les cartes de niveau serveur en ont généralement.

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 un plateau SATA remplaçable à chaud; avec la fonctionnalité désactivée, retirer le disque ne posait pas de problèmes, mais un nouveau disque ne s'enregistrerait pas avant le redémarrage. L'activation du paramètre a fonctionné comme prévu, les lecteurs placés dans le plateau ont été immédiatement mis en rotation et disponibles pour le système d'exploitation.

Je sais que cette question est ancienne, mais j'ai eu un succès que je n'ai pas vu rapporté ailleurs. Avait un problème similaire sur un Dell Precision 380 aujourd'hui. Finalement, cela a fonctionné en combinant les é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 pourrait é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 se terminera probablement mal. Ma situation s'en moquait, mais la tienne pourrait l'être.

Exactement laquelle des commandes ci-dessus est nécessaire et dans quel ordre m’est inconnue pour le moment. Certaines commandes peuvent avoir besoin d'être répétées. Si je devais deviner, je dirais do dans l'ordre indiqué ci-dessus, puis un autre scsi_host scanne à nouveau à la fin. J'ai fait pas mal plus dans mes explorations.

La première commande (scsi_host scan) indique à la couche intermédiaire SCSI d'analyser tous les bus à la recherche de périphériques nouveaux / modifiés. La deuxième commande tente de réinitialiser la cible SCSI (unité de disque). Les deux derniers travaillent avec le pilote du contrôleur AHCI lui-même.

J'ai trouvé les articles en question principalement par un examen approfondi 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 fichier 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 d'affiner, alors je voulais partager cette information dans l'espoir de rapprocher les autres. Si je reçois plus d'informations, je modifierai cette réponse afin de refléter.

J'espère que cela t'aides.

Pour que hotplug fonctionne, le module acpiphp doit être chargé.

[root@example ~]# modprobe acpiphp

évidemment, si vous voulez que cela fonctionne au démarrage, vous devrez le configurer pour qu'il soit chargé au moment du démarrage - vous pouvez, par exemple, créer / modifier le fichier /etc/rc.modules (appelé par rc.sysinit) et ajouter la ligne suivante:

modprobe acpiphp

Souvenez-vous que si vous créez ce fichier dans chmod + x it, comme il est appelé de cette manière.