Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
Je veux retirer immédiatement les sdh et sdi mais pas possible de faire la commande
J'ai un message d'erreur qui me dit qu'ils sont "busy".
J'ouvre ma tour, je vire les deux disques en cause, je mets deux disques tous neufs.
Et je me lance dans la manipulation habituelle :
, puis
Ils sont bien "added"
Et quand la reconstruction est terminée je regarde le détail de md0
Au secours les amis, je suis perdu........
Merci beaucoup pour vos aides
Hors ligne
Il y a 10j je vais voir comment se porte ma grappe RAID6 et Ô malheur, elle ressemble à ça
Elle ressemble à ça ou elle est exactement comme ça ?
Une date de mise à jour (update time) du même jour que la date de création (creation time) et un nombre d'événements (events) de seulement 160 ne me semblent pas cohérents avec un ensemble RAID qui fonctionne depuis plus de 4 ans.
Et quand la reconstruction est terminée je regarde le détail de md0
Ce n'est pas le même ensemble RAID : la date de création et l'UUID sont différents.
Il vaut mieux montrer que raconter.
Hors ligne
Elle ressemble à ça ou elle est exactement comme ça ?
Une date de mise à jour (update time) du même jour que la date de création (creation time) et un nombre d'événements (events) de seulement 160 ne me semblent pas cohérents avec un ensemble RAID qui fonctionne depuis plus de 4 ans.
Non elle ne fait que ressembler à ça car je n'ai pas pensé un faire une capture d'écran de
Il y avait ça, c'est sûr :
Ce n'est pas le même ensemble RAID : la date de création et l'UUID sont différents.
C'est dingue, je n'ai fait que --remove puis fdisk, les deux nouveaux disques ont pris les mêmes lettres (sdh et sdi) que les disques enlevés et enfin --add.
Puis-je "réintégrer" les disques qui en spare dans la grappe ou c'est mort et il faut que je recréée une nouvelle grappe???
P.S : en tous cas merci pour ton retour
Hors ligne
Non elle ne fait que ressembler à ça car je n'ai pas pensé un faire une capture d'écran
Alors de quand date la sortie que tu as postée ?
Il y avait ça, c'est sûr
Avec exactement les mêmes numéros et noms dans le même ordre ?
C'est dingue, je n'ai fait que --remove puis fdisk, les deux nouveaux disques ont pris les mêmes lettres (sdh et sdi) que les disques enlevés et enfin --add.
En tout cas une chose est sûre : ce n'est pas ça qui a changé la date de création et l'UUID. Est-il possible que tu aies déjà complètement récréé cet ensemble RAID en 2018 ?
Le remplacement des disques a-t-il été fait à chaud (hotplug) ou y a-t-il eu arrêt et redémarrage de la machine ?
Puis-je "réintégrer" les disques qui en spare dans la grappe
Je ne pense pas car il n'y a pas assez de disques actifs pour que le RAID soit opérationnel.
Il vaut mieux montrer que raconter.
Hors ligne
Alors de quand date la sortie que tu as postée ?
Super vieille, j'avais sauvegardé un vieux --detail, j'ai juste modifié les deux de /dev/sdh1 et /dev/sdi1.
Avec exactement les mêmes numéros et noms dans le même ordre ?
Pour ça, je suis sûr :
Number Major Minor RaidDevice State
0 8 65 0 active sync /dev/sde1
1 8 81 1 active sync /dev/sdf1
2 8 97 2 active sync /dev/sdg1
3 8 113 3 removed
4 8 129 4 removed
5 8 145 5 active sync /dev/sdj1
6 8 161 6 active sync /dev/sdk1
7 8 177 7 active sync /dev/sdl1
8 8 193 8 active sync /dev/sdm1
En tout cas une chose est sûre : ce n'est pas ça qui a changé la date de création et l'UUID. Est-il possible que tu aies déjà complètement récréé cet ensemble RAID en 2018 ?
Le remplacement des disques a-t-il été fait à chaud (hotplug) ou y a-t-il eu arrêt et redémarrage de la machine ?
J'ai déjà eu un changement de disque à faire, surement en 2018 (je ne me souviens plus exactement). Le changement avait été fait par --remove, puis arrêt de la machine, changement des disques durs physiques, puis fdisk et enfin --add et reconstruction super longue vérifiée par "watch -n 1 cat /proc/mdstat" et pour finir "mdadm --detail --scan --verbose > /etc/mdadm/mdadm.conf"
Je ne pense pas car il n'y a pas assez de disques actifs pour que le RAID soit opérationnel.
Dommage. Un truc à essayer quand même ? Quitte à tout perdre, au moins que je me batte.....
Hors ligne
j'avais sauvegardé un vieux --detail, j'ai juste modifié les deux de /dev/sdh1 et /dev/sdi1.
Ça peut expliquer l'incohérence entre le nombre de active/working devices mentionné (9) et les disques présents (7).
Il ne faut pas mélanger les informations ni faire passer des informations obsolètes comme des informations récentes. Ça génère de la confusion et induit en erreur.
J'ai déjà eu un changement de disque à faire, surement en 2018 (je ne me souviens plus exactement). Le changement avait été fait par --remove, puis arrêt de la machine, changement des disques durs physiques, puis fdisk et enfin --add et reconstruction
Ce n'est pas ça non plus qui aurait pu changer l'UUID et la date de création.
Ce qui m'intéresse, ce n'est pas de savoir si la machine a été arrêté lors de la précédente reconstruction mais si la machine a été arrêtée entre le moment où mdadm --detail a affiché 2 disques "removed" et le moment où il a affiché 3 disques "removed", pour savoir si les disques ont pu changer de nom entre les deux.
et pour finir "mdadm --detail --scan --verbose > /etc/mdadm/mdadm.conf"
Ça, c'est une connerie.
D'une part ça écrase tout le contenu antérieur de mdadm.conf, y compris les paramètres de configuration généraux non spécifiques à l'ensemble RAID.
D'autre part, l'option --verbose fixe les noms des disques ou partitions qui peuvent être utilisés pour assembler la grappe. C'est normalement inutile car l'UUID est suffisant pour identifier les membres, et potentiellement risqué car les disques /dev/sd* peuvent changer de noms d'un démarrage à l'autre. Si lors d'un démarrage un membre prend un nom qui n'est pas dans la liste initiale, alors il ne sera pas utilisé et sera considéré comme manquant.
C'est cette potentielle instabilité des noms des disques /dev/sd* (liée au caractère aléatoire de l'ordre de détection) qui complique les choses : le nom ne suffit pas pour identifier un disque dans les comparaisons avant/après. Il aurait fallu relever la sortie de mdadm --examine pour chaque membre pour avoir des informations sur son UUID propre, son numéro de membre dans l'ensemble RAID et son numéro de rôle et son statut.
Une chose a tenter, ce serait de retirer les 2 spares qui ne servent actuellement à rien, rebrancher les deux anciens et récupérer les informations de mdadm --examine pour toutes les partitions RAID.
Dernière modification par raleur (13-11-2021 11:17:19)
Il vaut mieux montrer que raconter.
Hors ligne
1Nao1 a écrit :j'avais sauvegardé un vieux --detail, j'ai juste modifié les deux de /dev/sdh1 et /dev/sdi1.
Ça peut expliquer l'incohérence entre le nombre de active/working devices mentionné (9) et les disques présents (7).
Il ne faut pas mélanger les informations ni faire passer des informations obsolètes comme des informations récentes. Ça génère de la confusion et induit en erreur.
Non, pardon, je me suis mal exprimé.
J'avais sauvegardé un vieux --detail en fichier .txt sur mon ordi pour garder une trace des commandes et de leurs réponses. J'avais utilisé ce vieux fichier .txt pour simplement imager ce que j'avais vu (en paniquant) avec les deux disques Removed. Je n'avais pas pensé à faire une capture d'écran à ce moment, je t'ai donc juste "modifié" le vieux fichier .txt pour te montrer le disques qui étaient devenus Removed.
1Nao1 a écrit :J'ai déjà eu un changement de disque à faire, surement en 2018 (je ne me souviens plus exactement). Le changement avait été fait par --remove, puis arrêt de la machine, changement des disques durs physiques, puis fdisk et enfin --add et reconstruction
Ce n'est pas ça non plus qui aurait pu changer l'UUID et la date de création.
Ce qui m'intéresse, ce n'est pas de savoir si la machine a été arrêté lors de la précédente reconstruction mais si la machine a été arrêtée entre le moment où mdadm --detail a affiché 2 disques "removed" et le moment où il a affiché 3 disques "removed", pour savoir si les disques ont pu changer de nom entre les deux.
Oui. Quand j'ai vu le --detail avec deux Removed, j'ai acheté deux nouveaux disques. J'ai arrêté ma tour, je l'ai ouverte et j'ai enlevé les deux disques et remplacé par les deux nouveaux. Ensuite j'ai créé des partitions pour chaque nouveau disque. Et une fois les -- add fait et la reconstruction faite, j'ai découvert un --detail avec trois Removed.
1Nao1 a écrit :et pour finir "mdadm --detail --scan --verbose > /etc/mdadm/mdadm.conf"
Ça, c'est une connerie.
D'une part ça écrase tout le contenu antérieur de mdadm.conf, y compris les paramètres de configuration généraux non spécifiques à l'ensemble RAID.
D'autre part, l'option --verbose fixe les noms des disques ou partitions qui peuvent être utilisés pour assembler la grappe. C'est normalement inutile car l'UUID est suffisant pour identifier les membres, et potentiellement risqué car les disques /dev/sd* peuvent changer de noms d'un démarrage à l'autre. Si lors d'un démarrage un membre prend un nom qui n'est pas dans la liste initiale, alors il ne sera pas utilisé et sera considéré comme manquant.
C'est cette potentielle instabilité des noms des disques /dev/sd* (liée au caractère aléatoire de l'ordre de détection) qui complique les choses : le nom ne suffit pas pour identifier un disque dans les comparaisons avant/après. Il aurait fallu relever la sortie de mdadm --examine pour chaque membre pour avoir des informations sur son UUID propre, son numéro de membre dans l'ensemble RAID et son numéro de rôle et son statut.
Une chose a tenter, ce serait de retirer les 2 spares qui ne servent actuellement à rien, rebrancher les deux anciens et récupérer les informations de mdadm --examine pour toutes les partitions RAID.
Je me suis "amusé" à faire --examine maintenant :
Le sdl1 me laisse perplexe...
Donc c'est ça, le --examine de chaque partition, que je dois sauvegarder quand je crée une grappe RAID ?
Je vais essayer de prendre du temps pour faire ce que tu m'as dit, remettre les deux anciens disques et faire --examine. J'ouvre simplement la tour et je change les deux disques et je rallume???
Hors ligne
Non, pardon, je me suis mal exprimé.
J'avais sauvegardé un vieux --detail en fichier .txt sur mon ordi pour garder une trace des commandes et de leurs réponses. J'avais utilisé ce vieux fichier .txt pour simplement imager ce que j'avais vu (en paniquant) avec les deux disques Removed. Je n'avais pas pensé à faire une capture d'écran à ce moment, je t'ai donc juste "modifié" le vieux fichier .txt pour te montrer le disques qui étaient devenus Removed.
J'avais compris que tu avais posté un vieux fichier en modifiant juste quelques lignes, d'où les incohérences.
Quand j'ai vu le --detail avec deux Removed, j'ai acheté deux nouveaux disques. J'ai arrêté ma tour, je l'ai ouverte et j'ai enlevé les deux disques et remplacé par les deux nouveaux.
Il aurait fallu rechercher pourquoi les deux disques étaient en removed avant d'envisager de les remplacer. Erreurs de lecture/écriture ? A priori ils n'étaient pas marqués "failed" ?
Est-ce que tu as aussi réécrit le fichier mdadm.conf à cette occasion (vérifie la date) ? Sinon, quel est son contenu ?
Le sdl1 me laisse perplexe...
En effet il est désynchronisé depuis le 5/11. C'était le disque actif n° 6 et le dernier état enregistré dans son superbloc était que l'ensemble était complet avec les 9 disques actifs. Une hypothèse est qu'une défaillance de ce disque est survenue pendant la reconstruction sur les deux nouveaux disques, interrompant celle-ci.
Il vaut mieux montrer que raconter.
Hors ligne
Il aurait fallu rechercher pourquoi les deux disques étaient en removed avant d'envisager de les remplacer. Erreurs de lecture/écriture ? A priori ils n'étaient pas marqués "failed" ?
Est-ce que tu as aussi réécrit le fichier mdadm.conf à cette occasion (vérifie la date) ? Sinon, quel est son contenu ?
Non, je n'ai pas modifié le mdadm.conf car j'ai vu le --detail qui était déconnant.
Il est du 25/02/2019 :
J'ai utilisé smartmontools pendant un moment pour faire des tests sur mes disques mais le rapport que je recevais toutes les semaines c'est arrêté, je ne me suis jamais plongé dans le pourquoi.... Donc le sdl aurait surement montré des faiblesses. Mince.
Si je remets les deux disques anciens, comme tu me le disais, que dois-je faire?
Merci
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1