Bonjour cher disk-gourus!
Voilà, le sujet de mon post est simple:
AU SECCCOOOUUURRRSSS!!!!!
(un peu d'humour ne fait pas de mal quand on est désespéré!!)
Tout d'abord, félicitations pour ce très bon topic riche en enseignements...
Je viens humblement vous exposer ma situation avec tous les détails nécessaires à une bonne compréhension... Mon post est long, mais je crois qu'il ne s'agit pas d'un cas d'école, il couvre en fait un éventail assez vaste de sujets liés aux problèmes disques, et qu'il devrait théoriquement trouver sa place dans ce topic déjà bien garni-i-i!!!
Je promets donc de m'exprimer dans un bon français pour que l'exposé de la situation puisse si possible servir à d'autre
Linuxiens... en y ajoutant un peu d'humour si possible pour rendre l'exposé moins rébarbatif...
Je compte enfin sur votre expertise (merci rmy, Skippy, et autres bonnes âmes) pour me dire ce que vous en pensez...
N'hésitez pas à me remonter le moral, je plaisante pour me rassurer, mais je vis très mal la perte de mon travail....
D'abord, et pour que vous puissiez comprendre ce film d'horreur en un clin d'oeil, voici un résumé de la situation actuelle, à l'heure où je poste ce message:
En résumé:
Je ne parviens pas à remonter sous Ubuntu 9.10 un système de fichiers RAID-0 (pourtant diagnostiqué sain) composé de 4 disques de 470 Go qui étaient originellement installés dans mon NAS de Thecus N4100. Le log système indique l'erreur principale suivante:
EXT2-FS Group Descriptors corrupted
(Note perso: Mouaifff... quand on a dit ça, on a tout dit, et on a rien dit... ça ressemble à une foultitude d'autres posts sur des sujets RAID... lisez la suite tout de même...)
Intermède:
Les détails qui suivent (nécessaires) sont longs. Si vous souhaitez une synthèse, allez au paragraphe final "Synthèse"; vous pourrez éventuellement revenir aux détails si mon cas vous interpelle....
Premières impressions / A savoir:
(1) Vous pensez peut-être qu'il s'agit d'un problème RAID et que cela ne concerne pas ce topic... Toutefois, j'ai procédé assez méthodiquement à des analyses, tests, j'ai écumé les forums sur le RAID, et comme vous le verrez ci-dessous, je crois que le problème à traiter se réduit en fait à un (simple?) problème de récupération d'un système de fichiers.
Toutefois, étant donnée la foule d'hypothèses, je manque de connaissances, et je ne trouve pas d'infos suffisamment détaillées sur mon cas spécifique pour résoudre ce problème...
(2) Je ne suis pas un "super super" expert système Linux / Disques, mais suffisamment informé pour réussir à me dépatouiller d'un assez grand nombre de situations. Suffisamment expérimenté aussi pour savoir que quand on croit savoir, il convient en fait de rester humble, de ne pas hésiter à demander conseil, et qu'en l'espèce, et malgré mes efforts pour rester rationnel et prudent, il est possible que j'ai commis quelques erreurs dûes à des instants de panique dans la résolution de ce problème... Dans la suite de cet historique, je vous ferai part de mes "erreurs"; néanmoins, ayant tenté d'agir avec prudence, ces erreurs (sauf peut-être une) ne devraient pas théoriquement avoir de réelle conséquence fâcheuse.
A vous de juger...
(3) Techniquement, vous pouvez de façon certaine considérer comme garanties les hypothèses de travail suivantes:
(a) Le NAS Thecus N4100 n'est absolument pas défaillant: j'ai acheté cet appareil il y a 4 ou 5 ans; il marche parfaitement (encore maintenant). Je n'ai pas d'actions chez Thécus, mais pour faire court: voià bien le seul et le meilleur investissement informatique que j'ai fait ces dernières années... Increvable cet appareil... Jusqu'à ce que l'erreur HUMAINE (mais oui... moi-même en l'occurrence!!) qui a déclenché ce cauchemar ne se produise, je disposais d'un NAS composé de 4 disques identiques de 470 Go/disque, montés en RAID-0 (peut-être pas le meilleur choix de RAID, mais il y a 4 ou 5 ans, cet équipement était cher et j'avais besoin de d'espace disque), soit une capacité totale d'env. 1.6 To.
Sur le RAID, j'ai stocké des données essentielles pour différents travaux, dont notamment deux projets (en cours) que je souhaite offrir à la communauté open-source, soit environ 18 mois de travail.... disparus.
Ceci vous fixe donc l'enjeu: ces données sont essentielles, et je suis prêt à tout pour les récupérer... Mon intuition c'est que cela est possible car les données sont là, j'en suis certain (voir historique ci-dessous).
NOTE:
SVP, ne me dites pas: as-tu fait un back-up de tes projets+données? En fait, techniquement, il est nécessaire que le projet s'exécute à partir du NAS, et les données ( par exemple, des images d'OS, ou une grande quantité de contenus multimédia) font partie intégrante du projet comme données de tests... impossible donc de backuper de telles quantités de données à moins de m'équiper d'un second disque de même capacité... En un mot comme en mille, j'ai considéré (avec raison) que le NAS est mon équipement le plus sûr pour le stockage de mes données. Et vu le nombre de pannes rencontrées sur d'autres matériels (laptops et autres ordis...) ces dernières années, et vu le fait que le NAS tourne comme une horloge 24/7, à même le sol en compagnie de quelques "moutons" (de passage)... bref, autant dire que cet équipement est fiable, et qu'il était raisonnable de le considérer comme un medium de stockage fiable, en attendant de pouvoir m'offrir une solution de stockage plus récente et moins onéreuse. Ce n'est donc pas une erreur matérielle, mais bien une erreur humaine dans un contexte de projet où un back-up était financièrement hors de ma portée...
En clair: si j'avais pu le faire, j'aurais évidemment backupé mes données de test, mais je n'ai pas les moyens de m'offrir deux fois le même équipement... ai-je clarifié toute ambiguïté?.... :-). Je me sens déjà assez mal comme ça....
(b) Les 4 disques RAID sont en parfait état physique (au moins une bonne nouvelle!). Aucune défaillance mécanique et/ou électronique à noter, car elle permet quand même d'orienter des solutions...
Maintenant l'historique détaillé des évènements:
Historique:
(1) Jour 0, Round 0, courant février 2010
Je travaille sur un projet (open-source) qui prévoit de proposer une solution clés en main de serveur de distribution / installation d'OS Linux / Windows en réseau. Le projet est basé sur la spec PXE, normalisation d'une structure de répertoires installable sur tout disque accessible en réseau via TFTP. Le projet inclut aussi (et c'est le module le plus important) un atelier de création, configuration d'images Windows customisables. Un très gros morceau de programmation, essentiellement basé sur un framework extensible écrit en DOS Batching... Un cauchemar de programmation quand on est habitué aux joies du Bash. Lors d'un test, une variable mal réglée, et Patatras: à l'issue de son exécution le script principal (qui lance l'exécution de la génération d'une image Windows XP et son déploiement dans le serveur PXE, soit env. 40 minutes d'exécution) efface le script principal lui-même.... AAArrrgggghhh!!! Le cauchemar vient de commencer, mais à cet instant, celles/ceux d'entre vous qui programment régulièrement et ont déjà connu ce type d'instant, vous savez qu'il s'écoule généralement env. une minute pendant laquelle votre cerveau est subitement traversé par une sorte de... vide...
Oui, je programme depuis plus de 25 ans, et cette situation, je ne l'ai connue que 3 fois. Donc, je ne suis évidemment pas parfait dans l'art de la prudence, mais raisonnablement, je crois que 3 fois en 25 ans, ça va... que celui qui programme depuis aussi longtemps et qui n'a JAMAIS connu cela me jette la première pierre...
Ah, et puis au fait, puisqu'on en parle... et bien oui, justement, j'avais un back-up du script principal daté de la veille, mais hélas inexploitable en l'état vu le très grand nombre de changements effectués dans l'intervalle de temps, et impossible de repartir en codage de ce script backupé. Il fallait absolument récupérer le script dans son état courant....
(2) Jour 0, Round 1: Récupération du script effacé sur le NAS
Après le vide intersidéral qui vient de traverser mon cerveau quand je constate que mon script n'est plus là, suivi du hurlement bestial intérieur "Ché pas possible!!!", je reprends mes esprits et me résouds à traiter (euh... calmement?) le problème: récupérer le script.
Problème: un NAS (en tout cas, chez Thécus), c'est plutôt le genre: boîte noire.... donc, la question est comment récupérer ce fichier alors qu'aucune fonction undelete n'est disponible sur le NAS.
Après quelques recherches sur le net, je découvre que PhotRec est THE outil (merci Christophe Grenier) qu'il me faut absolument essayer pour récupérer mon script. Je dois donc installer PhotoRec sur le NAS, l'exécuter avec un bon paramétrage, croiser les doigts, et on verra bien...
Heureusement, Thécus a eu la bonne idée d'upgrader le firmware du N4100. Je n'avais pas voulu tenter l'expérience de l'upgrade, car après tout, l'upgrade ne corrigeait pas réellement le fonctionnement initial du NAS (pour moi très correct), mais apportait plutôt des nouveautés, dont une, en fait assez sympathique: la possibilité d'ajouter des plug-ins fonctionnels au NAS, et notamment, une fonctionnalité media-center...
- J'upgrade le Firmware et grand bonheur, ej dispose maintenant d'un plug-in dont j'avais VRAIMENT besoin: le plug-in SSH.
- J'installe le plug-in SSH, je me connecte en mode console sur le Thecus, ça marche... YESSSS!!! L'autre bonne nouvelle, c'est que de nombreux utilisateurs Thécus rapportent qu'il est possible d'installer des programmes supplémentaires dans le firmware du Thecus... Alors on y va....
- Le firmware du Thecus N4100 est un système Linux basé sur Debian, et compilé semble-t-il pour une architecture processeur ARM.
- Comme je ne parviens pas à trouver PhotoRec pré-compilé pour cette architecture processeur j'entreprends de le cross-compiler si possible en statique. (Je passe les détails...). PhotoRec se compile en dynamique, mais le make échoue en statique.
- Impossible d'exécuter PhotoRec en librairie dynamique sur le Thécus. De mémoire: il manque des librairies et/ou les librairies du Thécus ne sont pas au bon niveau ou tout simplement incompatibles...
- Conclusion: il faut absolument compiler PhotoRec en statique, mais je ne trouve pas dans le makefile ce qui provoque le problème qui fait échouer le linkage. Désespéré (et très inquiet) en fin de journée, je me résouds à prendre contact avec Christophe Grenier (auteur de PhotoRec, merci Christophe!!), qui me répond avec beaucoup de gentillesse quelques jours plus tard.
(3) Jour 0, Round 1 ERREUR 1:
- ERREUR: être passé à l'action immédiatement.
L'aide que m'a fourni Christophe m'aurait sans doute permis d'éviter ce qui suit ci-dessous. Je pourrais m'auto-flageller 1000 ans en me répétant qu'il eût été plus prudent de rester sur la stratégie initiale: récupérer mon script en installant et en exécutant PhotoRec sur le NAS. Cela est sans doute vrai. Mais sur l'instant, le facteur humain, la fatigue, ont été les plus forts.
- DECISION (très mauvaise): je prends la décision d'extraire les 4 disques durs du NAS, je cours acheter des boîtiers USB, afin de remonter le RAID sous un Linux plus conventionnel (Ubuntu), et exécuter PhotoRec sur le RAID ainsi remonté.
NOTE: avant de prendre cette décision, je parcours quelques forums qui semblent indiquer que cela est possible, et que l'outil mdadm est l'outil de prédilection pour cela.
(4) Jours 1 + 10zaine de jours suivants, Round 2: remontage du RAID impossible...
- Mes 4 disques durs sont dans des boîtiers externes USB. Chaque disque a été numéroté dans son ordre d'emplacement initial dans le NAS, afin d'éliminer toute suspicion relative à l'ordre des disques lors de leurs assemblage (les forums RAID indiquent que l'ordre des disques importe).
- Beaucoup de documentation + forums parcourus sur le RAID et en particulier sur l'outil mdadm et son fonctionnement.
(a) ERREUR 2: vitesse et précipitation
[NOTE: je passse les détails de ligne de commande sur mdadm, car ils ne sont pas (sauf erreur de ma part) au centre du problème]
- Pensant agir d'une façon prudente je branche le premier des 4 disques et je lance la commande d'assemblage RAID mdadm sur ce disque. mdadm me gronde en indiquant que le RAID ne peut pas être assemblé.
- Explication: évidemment, idiot que je suis: en RAID-0, chaque fichier est découpé, et chaque morceau dispatché sur un disque du RAID. Pour reconstituer un système de fichier RAID-0, il est donc nécessaire d'assembler en une seule fois TOUS les disques, faute de quoi, le RAID, il va forcément marcher moins bien.... ou pas du tout.
- Cette erreur toutefois, ne devrait pas avoir de conséquences: je ne pratique aucun diagnostic en écriture sur le disque 1 du raid, par conséquent, il est intact.
(b) ERREUR 3: et si on continuait à faire des bêtises???....
- Bon, à ce stade du récit, vous vous dites: "A y est!! Il est parti en sucette... Qu'est-ce qu'il va encore faire?"
- Réponse: une erreur.
- Pourquoi? Après l'échec d'assemblage du RAID en (a), j'ai un doute qui m'assaille: et si j'avais involontairement endommagé mon ensemble RAID en tentant de le monter dans un autre contexte que celui du NAS?
- Pris dans ce doute, je veux vérifier que mes 4 disques peuvent toujours se réassembler sans problème dans le NAS. Je prends donc mes 4 disques, je les replace dans l'ordre initial dans le Thecus, je relance le NAS, et là, horreur: le NAS mouline un certain temps au boot, entre deux et cinq minutes (inhabituel), puis m'affiche que mon RAID n'est pas configuré. Plus aucune donnée visible sur les disques....
- Question: que s'est-il passé dans le NAS? Ne me dites pas qu'il a effacé mes données, ou bien la table des partitions, ou pire: reformaté les 4 disques..... Le formatage de 1.6 TB prendrait de toute façon plus de temps que 5 minutes, et un simple file check avec auto-correction certainement plus de temps aussi...
- Confirmation? Aucune confirmation, ni aucune information obtenue sur le net concernant ce que le NAS a fait lors de ce boot. Là où çà pêche chez Thécus, c'est vraiment au niveau des informations très techniques sur leurs produits, enfin, en tout cas pour des produits un peu anciens comme le N4100.
Peut-être le NAS n'a-t-il rien fait à part un file check, et s'est juste contenté de m'indiquer qu'il y a un problème qui l'empêche de retrouver ses données, et qu'il considère donc que le RAID n'est pas configuré. De plus, je ne parviens pas à trouver une trace de cela dans les logs du Thecus. Donc, ce qui est très problématique, c'est que je ne peux en rester qu'aux stade des hypothèses.
Si vous avez des explications ou autres hypothèses à formuler, n'hésitez pas, même si c'est pour me faire part d'une mauvaise nouvelle (cela m'évitera au moins de me fourvoyer):
Hypothèses:
* Niveau de risque sur cette erreur: ELEVE, car je ne sais pas ce qu'a fait le NAS.
* Risque lié à un file check effectué par le NAS: impossible de dire si le NAS a vraiment effectué un file check, pourquoi il l'aurait fait, et s'il l'a vraiment fait, a-t-il tenté une réparation automatique qui aurait éliminé les données, et tout cela en l'espace de deux à cinq minutes qu'a duré le boot. Pour moi, ce type d'opération aurait pris plus longtemps, donc très improbable.
* Risque de perte des données: MOYEN/FAIBLE: il est quand même peu probable que le NAS reformatte des disques sans rien dire, quand il ne détecte pas un système RAID configuré. Et encore une fois, s'il devait reformater, il reformaterait probablement les 1.6 TB, soit plus de 5 min de boot nécessaires avant d'être disponible.
* Risque d'effacement de la table de partitions: POSSIBLE. Cela traine dans certains forums concernant les NAS, avec une réinitialisation de la table de partitions quand le RAID n'est pas initialisé correctement.
La question de fond, la question principale:
J'allais oublier la question qui précède les autres:
* Pourquoi le NAS ne peut-il plus subitement réassembler 4 disques que j'ai seulement tenté de remonter sous Linux, en prenant soin de ne rien écrire dessus?
Suite des évènements:
- Ni une ni deux, j'éteinds proprement le NAS, je remets les disques dans leurs boitiers USB, les reconnecte à Ubuntu car je sais qu'à partir de maintenant:
* Je ne suis plus en face d'un problème de récupération de fichiers, mais
* En face d'un problème de récupération d'un système de fichiers,
* Il m'est devenu impossible de retrouver mes données dans le NAS,
* Il va falloir trouver une solution qui passera par un remontage du RAID + récupération du système de fichiers EN DEHORS du NAS.
Points négatifs:
- J'ignore si j'ai perdu mes données en remettant mes disques dans le NAS
Points positifs:
- N'ayant (a priori) exécuté AUCUNE opération de lecture / écriture sur le NAS après le boot, il n'y a (encore a priori) pas de raison logique (sauf si c'est le mode de fonctionnement du Thécus par défaut), pour que les données et/ou les partitions aient été effacées.
- Un autre argument (mais j'anticipe un peu sur les résultats d'assemblage RAID effectués aux étapes suivantes): l'erreur que je vais rencontrer aux étapes suivantes est une erreur fréquemment rencontrée par des utilisateurs RAID lors de l'assemblage de leur RAID sous Linux avec l'outil mdadm. Et dans un grand nombre de cas, l'erreur est le symptôme de causes multiples. Evidemment, il serait faux de tenter de me rassurer et de me convaincre bêtement qu'il y a forcément une explication autre que la perte de données, mais la réalité des cas rencontrés semble indiquer que tant que des disques n'ont pas de problèmes physiques et/ou mécaniques, tant qu'on parvient à réassembler un RAID sain, en général, il y a souvent une chance non négligeable pour que les données soient toujours là, mais inaccessibles en raison d'un problème de paramétrage ou de table de partition effacée. Alors pourquoi serai-je l'exception à cette note d'espoir???
(c) PROBLEME RAID: assemblage RAID incohérent
- Lors de mes essais suivants, j'ai compris la grossiereté de mon erreur commise en (a) (il était temps!), et j'assemble maintenant sous Ubuntu mes 4 disques connectés dans leur ordre de numérotation avec mdadm.
- Malheureusement dans cette phase d'essais qui dure plusieurs jours, je suis confronté à un problème de Superblocks.
- Et là, je suis un peu perdu. lors de la création/assemblage mdadm m'indique qu'il ne trouve pas de superblock permettant de réaliser un assemblage correct des disques.
Donc, l'assemblage RAID via mdadm ou bien échoue, ou bien je me retrouve avec un assemblage RAID incomplet et incohérent...
De plus dans la documentation et les forums traitant ext2/ext3, il est également fait mention des blocs et super-blocks...
- Parle-t-on de la même chose en fait?
- Après quelques jours de galère sur les forums et sur la documentation ext2/ext3/raid, j'arrive à comprendre (enfin grossièrement) que d'un côté, la structure-même de ext2 prévoie la notion de noeuds pour le stockage et l'organisation physique des données, les superblocks sont également utilisés, entre autres, pour la table de partition du disque.
- Sur la documentation RAID, les superblocks sont également mentionnés, mais leur utilisation, sauf erreur de ma part, serait destinée à contenir des méta-informations permettant de réaliser un lien logique entre plusieurs disques physiques et/ou partitions qui seront ensuite assemblable ensemble. La littérature sur mdadm mentionne également l'UUID du disque RAID assemblé, qui doit être inscrit et identique sur chacun des 4 disques. Je comprends que grosso modo les superblocks RAID devraient donc (entre autres) contenir l'information d'identification d'un disque dans un contexte d'assemblage RAID, où le disque RAID final assemblé aura le même UUID que chacun de ses membres...
- Ces éléments assez théoriques sont, de mon point de vue, confirmés sur des forums où l'on indique que dans ce type de situation, il suffirait (conditionnel) de regénérer les superblock RAID sur les disques pour être en mesure de les assembler correctement.
- Sans rentrer dans les détails: j'utilise les options de commandes de mdadm pour regénérer les superblocks raid.
NOTE IMPORTANTE:
Durant toutes mes manipulations, cette opération en écriture sur les disques est la seule que j'ai volontairement effectuée.
- J'exécute:
sudo blkid
- J'obtiens 4 disques avec le status "linux raid member" pour chacun, et avec des UUID identiques. Parfait!
- Après moults essais, je tente de réassembler l'ensemble RAID via mdadm sur /dev/md0:
sudo mdadm -A /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
mdadm: /dev/md0 has been started with 4 drives.
Ca marche!!!
NOTE:
Ca marche, mais quand même... je suis un peu perturbé par mdadm. Pas par le dernier essai ci-dessus qui a réussi, mais lors
de de plusieurs essais précédents avec la commande d'assemblage. J'avais essayé différentes combinaisons de switches, et notamment, j'avais du essayer un truc comme:
sudo mdadm --assemble --scan
Au lieu d'assembler explicitement les devices et de préciser leur ordre d'assemblage, je laissais mdadm scanner les devices et assembler les device détectés. Lors de ces essais donc, mdadm analysait et assemblait les 4 disques un par un et pour la phase d'assemblage, il renvoyait dans la console les infos suivantes (je ne me souviens plus exactement des messages exacts, mais il s'agissait de quelque chose comme):
* disque 1: seems to contain an ext2fs partition
* disque 2: (rien de special)
* disque 3: (rien de special)
* disque 4: (rien de special)
Avec le dernier essai: mdadm -A /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3, je n'obtiens plus ces messages. Toujours est-il que cela me perturbe car le disque 1 semble être vu différemment des 3 autres disques.
Hypothèses 1 et 2: quelqu'un sait-il?
Cela me perturbe car, si on admet que les 4 disques d'un RAID0 doivent être exactement partitionnés de façon identique, alors on pourrait s'attendre à ce que les 4 disques, et non pas un seul, disposent effectivement d'une partition ext2fs... Ou bien, autre hypothèse sur laquelle je n'ai pas trouvé de réponses: le disque 1 d'un RAID-0 contient peut-être seule les informations de partitionnement, tandis que les autres disques n'ont pas besoin de cette information déjà contenue dans le disque 1 qui serait alors un disque "maître" pour un RAID-0...?
Ce que j'écris a-t-il du sens pour vous? A moins que vous ne disposiez de connaissances sûres en RAID-0 qui pourraient lever ces questions, au moins peut-on admettre qu'il est logique de se poser ces questions...
Hypothèse 3: après tout, pourquoi pas...
Enfin, il y a la troisième hypothèse qui me vient à l'esprit tandis que je vois ces messages: et si la ré-écriture des superblocks RAID via mdadm avait tout simplement effacé les informations de partition sur les disques 2, 3 et 4...
Hypothèse 4: et après, ils diront que je suis totalement fou!!!
Ben, tant qu'on y est, pourquoi ne pas s'interroger sur le partitionnement d'un RAID-0. J'ai eu beau chercher des informations sur le Net, je n'ai rien trouvé de spécial à ce sujet. Le RAID-0 est moins bien documenté que les autres RAID.
Mais ce qu'il ressort de ce que j'ai lu, c'est qu'a priori, il est difficile de prédire de quelle façon un RAID sera partitionné, le partitionnement (ou pas) pouvant dans certains cas (cartes contrôleur RAID, NAS?) résulter d'un processus propriétaire. Là, on retombe d'ailleurs sur les questions concernant le NAS et ce qu'il a "bricolé" pendant son boot à l'étape (b) ci-dessus.
Dans mon cas, il est certain qu'aucune carte contrôleur RAID n'est intégrée dans le NAS. Il s'agit bien RAID software. Reste à savoir si le Thécus N4100 réalise effectivement le partitionnement de ses disques RAID. Si la réponse est non, d'où provient donc cette partition ext2 présente sur le disque 1, tandis que les disques 2, 3, et 4 n'en possèdent pas?
Comme vous le voyez, ce n'est pas faute d'essayer de raisonner, mais je manque de connaissances théoriques sur ce sujet....
- Je referme cette parenthèse, car au final, la commande d'assemblage mdadm semble s'être terminée pour la première fois sans échouer.
Hein? Quoi? Serait-il possible que.... oui.... serait-il possible que j'ai réussi malgré tout????
(A genoux devant le clavier, transpirant et tremblant): "ÔÔÔÔÔ toa, seigneur Oubountou, donne-moi la force... oui, donne-moi la force de taper encore quelques commandes sur ce clavier..."
- Puis un coup de:
cat /proc/mdadm
arrosé d'un coup de:
sudo mdadm -D /dev/md0
me renvoient tout tranquilou l'information qu'un ensemble RAID /dev/md0 est présent, assemblé, sain et est constitué de 4 disques chacun dans un état "active sync", soit un ensemble RAID de 1.6 TB.
"Merci à toi, Ouboouuuuuntou!!!"
(J'ai regroupé à partir de l'étape (10) les messages renvoyés par ces commandes).
- Là, à environ Jour 0 + 10 ou environ, je commence enfin à respirer. Naturellement, je suis loin de me douter que les problèmes ne sont pas terminés.... Enfin quand je dis "je suis loin de me douter...", j'exagère un peu, en fait: avec quelques années d'informatique dans les pattes, le "pif" a tendance à se développer un peu, même chez les plus optimistes d'entre nous, si bien que dès qu'on obtient un succès dans la résolution d'un problème, on a généralement acquis le réflexe conditionné qui consiste à éviter de se réjouir trop vite en faisant la danse sioux autour de l'ordi... Non, en fait, avec le pif un peu développé, on a plutôt tendance à se dire simplement et calmement: c'est déjà ça....
- Car il reste l'épreuve finale: remonter le système de fichiers RAID.
- "RRROOââaaahhhh, l'autre...." allez-vous me dire en rigolant... "Trop facile, fingueurz in ze noze". Oui, en fait, c'est exactement ce que je me suis dit en reprenant mon souffle après la danse sioux.
- Allez, un coup de:
sudo mount /dev/md0 /home/moi/mon_raid_adoré
Et voilou!!! Mount renvoie:
mount : type erroné de syst .de fichiers, option erronée, super bloc
erroné sur /dev/md0, codepage ou aide manquante ou autre erreur
Dans quelques cas certaines informations sont utiles dans syslog - essayez
dmesg | tail ou quelque chose du genre
Ah ben oui mais non!! Ce n'est pas vraiment ce que j'attendais!!
D'autres problèmes en perspective... donc!
- Redocumentation sur le net, forums, etc.
(5) Intermède:
Après presque 3 semaines en Février intensives passées sur cette situation qui se dégrade de plus en plus (par ma faute), enfin, une situation dont je ne vois pas le bout du tunnel, je décide de faire une pause d'une semaine ou deux pour les raisons suivantes:
(a) Je suis au bout de toutes les solutions que je pensais pouvoir mettre en oeuvre, et je suis réellement abattu, c'est rare...
(b) Raisons professionnelles
(c) Un principe de précaution (à la mode?): se documenter, encore, encore avant d'entreprendre une quelconque action
(d) A la fin de l'étape (4), je découvre que je vais peut-être devoir entreprendre des actions de corrections en écriture sur les disques. Quelque soit l'action à entreprendre, il est hors de question d'effectuer une quelconque opération sur les disques d'origine: il va falloir travailler sur des images disques.
(6) Mars 2010, Round 3
- J'ai remonté un peu la pente moralement, et me sens prêt pour un nouvelle quête de mes données... Bon, on ne parle même plus de récupérer mon script Batch DOS ce serait la cerise sur le gâteau... si le journal du FS n'est pas récupérable il y aura bien peu d'espoir. Enfin, on pourra toujours espérer encore avec PhotoRec si je récupère d'abord le système de fichiers intact....
- J'ai fait l'acquisition d'un Fujitsu StorageBird 2 To USB acheté chez mon Auch... favori afin de stocker les 4 images disques que je vais créer et sur lesquelles je vais travailler.
- Autant vous le dire tout de suite: si je cite la marque et modèle du disque dur, c'est que je vous déconseille FORTEMENT l'achat de cette M#&de. Un boitier Fujitsu, un disque dur Hitachi. Bref, vous allez voir que comme si les problèmes existants n'étaient déjà pas suffisants avec l'énergie que l'on dépense à trouver des solutions pour les résoudre, on va en rajouter une couche dont on n'a vraiment pas besoin afin de satisfaire la sacro-sainte Loi de Murphy.
- Stratégie de base: créer 4 images disques brutes sur le disque dur 2To
- Faisable? Ben voui.
dd if=/dev/disque1 of=/dev/storagebird/disque1.dd
et ainsi de suite pour les 3 autres disques.
- C'est parti.
- Euh... non. Attendez!! J'ai oublié de préciser. Comme j'avais vraiment la patate, je me suis autorisé un peu d'optimisme:
* Achat d'un Hub USB 6 port avec alimentation externe optionnelle
* Branchement des 4 disques RAID en USB sur le Hub
* Le StorageBird branché directement sur le second port USB de l'ordi
* Afin d'éviter tout problème de mise en veille des disques: désactivation des fonctions de gestion de l'énergie au niveau des disques
Bref, j'ai tout prévu!!! Ah!! Ah!!! Plus rien ne m'arrêtera!!!
Un peu de calcul théorique. Débit max USB: env. 30 Mo/s. Mon RAID est rempli à 80% de la capacité théorique max des disques (480 GB) soit environ 4 x 375 = 1500 GB. Bon, c'est un calcul à la louche, évidemment. Avec le débit en lecture d'environ 30 MB/s, il faudra environ 15 heures pour créer les 4 images...
Alors vous allez dire: "on s'en moque...". Ah ben oui mais non. Je mentionne ce point pour que quelque chose soit clair à l'esprit de celle ou celui qui en passe par là: si vous décidez de travailler sur des images disque, soyez conscient qu'une fois que vous aurez tenté une ou des actions correctives de quelque nature que ce soit sur vos images, et dans le cas malheureux où elles n'ont pas abouti, et bien:
* Vos images disque sont consommées, inutilisables, et bonnes pour la poubelle
* Il faut recréer les images du ou des disques puis recommencer d'autres action correctives.
Tout cela pour dire et je répète ce que dit parfaitement rmy: être patient, mais surtout, sélectionner le mieux possible QUELLE(S) action(s) corrective(s) sera(ont) à effectuer.
A ce titre, et je referme la parenthèse, je me permets d'ajouter dans ce topic un point qui ne m'a pas semblé être mis en avant dans les posts de conseil (ou peut-être ne les ai-je pas lu). Si vous exécutez des actions de diagnostics sur un disque original, essayez toujours des les effectuer en mode lecture seule (même si l'action perd de son efficacité).
Par exemple, sur les disques originaux de mon raid, je me suis TOUJOURS limité à des commandes de type: efsck -n /dev/un_disque afin de garantir qu'aucune modification involontaire n'était effectuée sur un disques traité.
Cette remarque permet aussi de comprendre pourquoi le scope des actions que l'on peut effectuer sur des disques physiques d'origine est en fait assez limité. Très vite, si l'on veut réellement voir ce que produisent vraiment des commandes de réparation telles que e2fsck (ou testdisk), il devient évident qu'il va falloir travailler avec des images des disques afin de se garantir un risque 0.
- Parenthèse refermée.
- Essai 1: Vers 23 heures, je lance mes 4 dd simultanément sur mon Hub USB et pars faire un gros dodo (en fait, pour être tout à fait honnête, j'ai utilisé l'outil ddrescue qui offre de meilleures garanties contre les erreurs éventuelles).
Au matin, 7 env. 7 heures de copie, ça roule, je ne touche pas à la machine, je bricole à côté. Au bout d'environ 10 heures, mes 4 images sont (presque) présentes sur le storagebird avec presque 300 Go de stockés pour chaque image. Vers 10 heures et quelques minutes, le storagebird attend traitreusement que j'ai le dos tourné pour une pause "petit coin", et quand je reviens: PPPPOOiiimmppp!! Erreur d'écriture sur le disque, des messages pas clairs, et tout le tremblement....
Euh... comment dire? Je suis à cet instant traversé par une vague envie de me saisir de ce nouveau disque dur et de lui coller une baffe, mais je me ravise finalement: il paraît que ça ne sert à rien.
Plus sérieusement: examen des logs système. A l'évidence, le Hub fonctionne bien. Chaque disque USB à lire a fonctionné correctement. En revanche, côté StorageBird, le port USB indique une mise en veille inexplicable du port, avec les insultes habituelles d'erreurs I/O qui vont avec.
Résultat: Faute à pas de chance? Erreur reproductible? Chais pas. Trop tôt pour dire. Je recommence.
- Essai 2: on respire un bon coup et on y retourne....
Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 6 heures de copie. Une journée de travail ch#énte foutue.
- Essai 3: très vénère...
Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 1 heure de copie.
- Essai 4: très très très vénère...
Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 10 minutes de copie.
- Essai 5: si çà plante encore, je m'inscris à l'épreuve du lancer de disques aux prochain J.O, et je promets que j'amènerai mon propre équipement....
Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 2 heures de copie.
- Bilan: entre chaque essai documentation sur les forums. Je passe sur la réputation discutable et discutée des disques Hitachi, sur les (trop) habituels problèmes rencontrés sous Linux ou Mer#~oze avec des disques USB qui se mettent en veille, est-ce le disque lui-même, est-ce le PCB qui est complètement foireux (soit-dit en passant ce serait la seule contribution réelle de Fujitsu dans ce produit) ?
Bref, j'ai tout lu. Gros abattement: non seulement je ne peux toujours pas récupérer mes données, mais en dépit de tous mes efforts (j'allais oublier qu'à partir de l'essai 3, j'ai acheté deux multiprises sophistiquées avec fusible intégré, la peau des fesses... et que chaque multiprise n'alimente que deux disques durs USB tandis que chaque multiprise est branchée dans une prise murale distincte... bref, je vous laisse imaginer le plat de spaghettis de câbles d'alimentation USB, cordons USB, hub USB, etc.).
Tout çà pour çà....
(7) Intermède:
- Je décide de retourner encore une fois sur les forums et à la pêche à la documentation.
- Pendant ce temps, je suis tellement agacé, qu'encore une fois, je décide de faire une pause de quelques jours afin de garder les idées claires. Heureusement mes obligations professionnelles m'auront au moins permis de me faire oublier ce problèmes pendant quelques semaines.
(8) Avril 2010, Round 4:
- Ca y est! J'ai la pêêêêche!!! Je suis un Ouineur!! Ca va pulser !!!
- J'avais carrément envisagé d'acheter un nouveau NAS (tant pis pour le prix) avec 4 ou 8 To pour y copier mes images disques, car avec un bon NAS, au moins, pas de problème de mise en veille intempestive. Mais j'ai abandonné cette idée. Trop cher mon fils, et puis un peu de bon sens: j'ai déjà perdu des données, acheté un DD de TB (plus de 180 EUROS); il va falloir faire avec ce qu'on a....
- RV avec le SAV de Auch... Effectivement, le problème semble connu, et pas seulement sur les 2 To, mais depuis les Storagebird 1 To. La question: est-ce que c'est le DD qui part en vrille, ou bien est-ce le PCB???
- Réponse de Auch...: y savent pas, mais les techniciens s'y connaissent un peu, et en plus (coup de bol), l'un d'eux est Linuxien, et il me conseille de démonter proprement le boitier et de brancherle DD 2To directement dans une machine... Si ça marche pas, je remonte le boitier, et eux renvoient au constructeur en exigeant un changement du matériel...
- Mouais... mouais... mouais.... :-/ cette idée, je l'avais déjà eue avant d'aller les voir. Je crois que j'aurais pu moi-même conclure que j'avais acheté une grosse m#~douille.... Mais ouvrir ma machine de bureau qui est un cauchemar dès qu'on modifie un branchement (un XPC Shuttle SN25P), retirer un disque pour faire mumuse avec un autre disque... Pfff... quel cirque....
Sans compter le fait qu'il y a un détail croustillant à propos des Fujitsu storagebird que vous serez heureux de connaître: les modèles StorageBird 1 To disposent de vis pour démonter le boîtier. Bizarrement, les modèles 2 To ont des boîtiers qui s'emboitent avec des clips plastique dans la masse du boîtier. En clair, si tu veux ouvrir ton StorageBird 2To, il faudra casser le boîtier à coups de tournevis, à moins d'être le champion du monde du démontage.... Moi, perso, je suis patient, mais vu l'assemblage du boîtier, j'ai vite compris qu'il m'était impossible de le démonter sans le casser.
Je suppose, et n'y voyez au pire que du mauvais esprit de ma part, que Fujitsu aura pris soin de mettre tout son génie dans le packaging de leur M#&-de plutôt que dans la qualité des composants et/ou de la conception du produit. Ils devaient peut-être en avoir assez d'être submergés de retour constructeur de leur daube qui "dort tout le temps". Moi, j'ai pas eu le choix: à l'heure où je poste, c'est le seul DD 2To que j'ai pu trouver en rayon, et manque de bol, il était vendu dans un boîtier...
Oui, oui, vous allez dire: "mais peut-être que c'était seulement un défaut sur le modèle que tu as acheté...". C'est vrai, et c'est pourquoi je me taxe de mauvais esprit par sécurité. Mais vu le feedback officieux des techniciens Auch.. sur les modèles 1To et qui semblent confirmer mon problème, et vu le nombre de messages concernant ces modèles sur différents forums, j'ai tendance à croire que vous mettre en garde contre ce modèle de disque dur est un service que je rends à votre porte-monnaie.
Et dire que je m'étais promis de ne pas acheter de disque dur pacakagé en boîtiers USB mais d'acheter de simple boîtiers sans électronique additionnelle...
- Première action: je fais une nouvelle tentative de création d'image. Cette fois-ci, j'effectuerai tout le processus sur ma machine de bureau (le Shuttle), plutôt que sur mon laptop (essais précédents): machine plus puissante, risque réduits concernant des problèmes éventuels d'alimentation, et surtout, cette fois-ci, je vire le Hub USB (bien que je suis persuadé qu'il n'est pas en cause), et je créerai 1 image à la fois. Pour cet essai, le disque Fujitsu est TOUJOURS dans son boîtier d'origine et branché port USB de la machine. Le disque dur RAID source est lui aussi dans un boîtier USB relié au second port USB de la machine...
C'est parti. Au bout d'env. 4 heures, plantage :-) Mêmes logs, mêmes erreurs, le disque dur Fujitsu est parti en sucette et s'est "endormi" pendant la copie.
- Deuxième action: prendre une décision. Si je renvoie le disque en SAV, plusieurs semaines d'attente... peut-être un nouveau disque dur StorageBird avec le même problème...
- Je prends le risque. Démontage (cassage sauvage du boîtier, ça défoule!!!), branchement du disque nu dans le XPC shuttle, et hop! en 10 minutes chrono, mon XPC Ubuntu 9.10 reboote et reconnaît le disque. Impeccable!! Au moins une chose à laquelle je peux me fier: le système d'exploitation !!!
- Je relance la création d'une image avec le premier disque dur RAID branché dans son boîtier externe USB. Débit 30 MB/s, soit entre 4 et 5 heures pour la création de l'image, si tout se passe bien.
- 4 heures et des poussières plus tard: ddrescue vient de me créer avec succès une image disque disk1.dd de 372.4 Go.... Finalement, mon estimation sur la taille finale des images n'était pas trop mauvaise. J'avais initialement estimé la taille à 375 Go...
- Conclusion 1: YOUPIIIIIIII!!!!!
- Conclusion 2: Plus sérieusement:
* Le disque dur Hitachi n'est (a priori) pas en cause. C'est le système de branchement/alim du boîtier du Storagebird qui est complètement foireux. Donc, vous savez maintenant ce que vous faites si vous achetez ce modèle....
* Comme initialement prévu et calculé, j'ai pu créer les 4 images des mes disques durs sur le disque 2 To.
* Je vais passer à l'assemblage des images en RAID dans l'étape suivante:
(9) Montage des images RAID members, Round 4, fin:
- Là pas de grosse surprise, mais tout de même, un petit test implicit. En général on peut se fier à l'image créée par ddrescue. Donc, si je pouvais assembler mes 4 disques physiques en RAID auparavant, j'espère que je pourrai obtenir (au moins) un assemblage de leurs images avec le même succès.
- Les étapes habituelles:
losetup /dev/loop0 /media/storage_bird/disk0.dd
losetup /dev/loop1 /media/storage_bird/disk1.dd
losetup /dev/loop2 /media/storage_bird/disk2.dd
losetup /dev/loop3 /media/storage_bird/disk3.dd
- Youplà! Ca marche... Mes 4 fichiers images disk0.dd, disk1.dd, disk2.dd, disk3.dd sont respectivement les loop devices /dev/loop0, /dev/loop1, /dev/loop2, et /dev/loop3.
- Maintenant j'assemble mes disques avec mdadm. Bon il y a plusieurs façon de le faire: j'utilise ici le switch -A pour l'assemblage, vu que chaque image disque est supposée avoir déjà été assemblée précédemment au sein du même array RAID et que par conséquent, les 4 images doivent avoir le même UUID.
sudo mdadm -A /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
me renvoie:
mdadm: /dev/md0 has been started with 4 drives.
- Résultat: YEEEEEEEEESSSSSSSSS! Ca marche.
- Un coup de:
cat /proc/mdstat
me renvoie les infos suivantes:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid0 loop0[0] loop3[3] loop2[2] loop1[1]
1562061056 blocks 64k chunks
- Et enfin arrosé par:
sudo mdadm -D /dev/md0
qui me renvoie les détails suivants sur le RAID /dev/md0 assemblé:
/dev/md0:
Version : 00.90
Creation Time : Fri Feb 19 01:23:02 2010
Raid Level : raid0
Array Size : 1562061056 (1489.70 GiB 1599.55 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Feb 19 01:23:02 2010
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : ecfe8404:2f354a45:d66856da:8e136666
Events : 0.1
Number Major Minor RaidDevice State
0 7 0 0 active sync /dev/loop0
1 7 1 1 active sync /dev/loop1
2 7 2 2 active sync /dev/loop2
3 7 3 3 active sync /dev/loop3
- Conclusion: mon raid sur/dev/md0 est bien assemblé, sain, en RAID 0, et constitué de 4 disques dans l'état "active sync".
- Rempli d'un espoir totalement irrationnel, j'essaie de monter le système de fichiers bien que je sais déjà qu'en toute logique, cela ne pourra pas fonctionner. On sait jamais, avec un coup de chance.... Mais euh... non. Même motif, même punition que précédemment. La commande:
sudo mount /dev/md0 /home/moi/mon_raid_adoré
me renvoie comme je le craignais:
mount : type erroné de syst .de fichiers, option erronée, super bloc
erroné sur /dev/md0, codepage ou aide manquante ou autre erreur
Dans quelques cas certaines informations sont utiles dans syslog - essayez
dmesg | tail ou quelque chose du genre
- Conclusion: bon, ben voilà. J'ai mes 4 images disques, je sais réassembler mon RAID, le système de fichiers ne se monte toujours pas. C'est normal.
- Faisons un coup de: fdisk -l pour voir comment est vu le disque /dev/md0. La commande me renvoie:
Disque /dev/md0: 1599.6 Go, 1599550521344 octets
2 têtes, 4 secteurs/piste, 390515264 cylindres
Unités = cylindres de 8 * 512 = 4096 octets
Identifiant de disque : 0x00000000
Le disque /dev/md0 ne contient pas une table de partition valide
- Ben voyons..... pas de table de partition... cha alors!!!
- Terminons maintenant par l'examen de messages.log pour voir ce qui s'est passé dans les coulisses pour l'assemblage du
RAID, et la tentative ratée de montage du système de fichier. J'imprime ici seulement la section de messages.log qui semble importante:
0000 May 1 17:30:17 obelix kernel: [ 482.249802] md: bind<loop1>
0001 May 1 17:30:17 obelix kernel: [ 482.249802] md: bind<loop2>
0002 May 1 17:30:17 obelix kernel: [ 482.249859] md: bind<loop3>
0003 May 1 17:30:17 obelix kernel: [ 482.249911] md: bind<loop0>
0004 May 1 17:30:17 obelix kernel: [ 482.268841] raid0: looking at loop0
0005 May 1 17:30:17 obelix kernel: [ 482.268849] raid0: comparing loop0(781030528)
0006 May 1 17:30:17 obelix kernel: [ 482.268854] with loop0(781030528)
0007 May 1 17:30:17 obelix kernel: [ 482.268858] raid0: END
0008 May 1 17:30:17 obelix kernel: [ 482.268861] raid0: ==> UNIQUE
0009 May 1 17:30:17 obelix kernel: [ 482.268864] raid0: 1 zones
0010 May 1 17:30:17 obelix kernel: [ 482.268868] raid0: looking at loop3
0011 May 1 17:30:17 obelix kernel: [ 482.268872] raid0: comparing loop3(781030528)
0012 May 1 17:30:17 obelix kernel: [ 482.268877] with loop0(781030528)
0013 May 1 17:30:17 obelix kernel: [ 482.268880] raid0: EQUAL
0014 May 1 17:30:17 obelix kernel: [ 482.268883] raid0: looking at loop2
0015 May 1 17:30:17 obelix kernel: [ 482.268888] raid0: comparing loop2(781030528)
0016 May 1 17:30:17 obelix kernel: [ 482.268892] with loop0(781030528)
0017 May 1 17:30:17 obelix kernel: [ 482.268895] raid0: EQUAL
0018 May 1 17:30:17 obelix kernel: [ 482.268898] raid0: looking at loop1
0019 May 1 17:30:17 obelix kernel: [ 482.268902] raid0: comparing loop1(781030528)
0020 May 1 17:30:17 obelix kernel: [ 482.268906] with loop0(781030528)
0021 May 1 17:30:17 obelix kernel: [ 482.268909] raid0: EQUAL
0022 May 1 17:30:17 obelix kernel: [ 482.268912] raid0: FINAL 1 zones
0023 May 1 17:30:17 obelix kernel: [ 482.268921] raid0: done.
0024 May 1 17:30:17 obelix kernel: [ 482.268925] raid0 : md_size is 3124122112 sectors.
0025 May 1 17:30:17 obelix kernel: [ 482.268930] ******* md0 configuration *********
0026 May 1 17:30:17 obelix kernel: [ 482.268934] zone0=[loop0/loop1/loop2/loop3/]
0027 May 1 17:30:17 obelix kernel: [ 482.268945] zone offset=0kb device offset=0kb size=1562061056kb
0028 May 1 17:30:17 obelix kernel: [ 482.268949] **********************************
0029 May 1 17:30:17 obelix kernel: [ 482.268951]
0030 May 1 17:30:17 obelix kernel: [ 482.268979] md0: detected capacity change from 0 to 1599550521344
0031 May 1 17:30:17 obelix kernel: [ 482.273463] md0: unknown partition table
0032 May 1 17:31:05 obelix kernel: [ 530.560739] EXT2-fs: group descriptors corrupted!
- Conclusion: intéressant.
* Lignes 0000-0003: lors de l'assemblage, mdadm fait en dernier le binding de /dev/loop0 (le premier disque raid physique), alors que pourtant je l'assemble explicitement comme premier device de l'ensemble RAID. Etrange? Ou bien pas important? Bref
* Lignes 0004-0023: je suppose que l'algorithme de mdadm compare les identifiants des disques 2, 3 et 4 avec celui du disque 1 (/dev/loop0) et/ou vérifie que les tailles des disques sont identiques. Cette phase, je suppose encore, doit permettre à mdadm de savoir que ces 4 disques sont logiquement assemblés ensemble...
* Lignes 0026-0027: est-ce que ces infos sont correctes? Comment vérifier leur cohérence de façon sûre? Intéressant de constater que l'ordre affiché des devices semble correct avec /dev/loop0 comme premier device. Cela pourrait venir confirmer que le premier disque d'un assemblage RAID-0 est considéré d'une façon un peu spéciale par rapport aux autres disques...
* Lignes 0029-0030: une fois assemblé, la taille du RAID est bien la sommes des tailles des 4 disques: a priori normal, mais qui indique donc aussi que les informations sur le remplissage du disque sont quand même lisibles... un bon signe, non?
* Lignes 0031-0032: ça, c'est ce qui se produit lors du mount. Donc, en gros, ce qu'il faut comprendre c'est que les descripteurs de groupe EXT2 sont nazes... Cela suffit-il à expliquer l'absence d'une table de partition???
Beaucoup d'utilisateurs RAID ont fait un constat similaire en utilisant mdadm avec des descripteurs de groupes a priori nazes, mêmes sur des disques en assemblage RAID qui n'ont subi aucune modification par rapport à l'instant t-1 où ces mêmes disques fonctionnaient encore parfaitement...
Donc, à ce stade, ma situation ressemble exactement à celle des autres. Il y a néanmoins une différence avec les autres utilisateurs qui ont reporté ce type de problème. Dans la plupart des cas, la solution qu'on leur a proposée sur des forums fonctionnaient, car la solution proposée étaient adaptée à leur RAID, le plus souvent de type RAID-5, solutions qui s'appuient sur un réassemblage partiel des disques afin de forcer une ré-écriture des superblocs RAID, et je ne sais quoi encore...
Malheuresement, aucune solution même inspirée de ces solution n'est applicable à mon cas de RAID-0, car TOUS les disques sont nécessaires simultanément. C'est la raison pour laquelle j'avais forcé la regénération des superblocs RAID, ce qui, jusqu'à présent à au moins permis de garantir le lien logique d'assemblage entre les 4 disques.
Malheureusement, aucune solution en vue pour la reconstruction de la table de partition.
- Alors quelle différence avec "AVANT" les images disques?
Simple: maintenant, je vais pouvoir effectuer les opérations correctives (écriture) que je me suis interdit de faire jusqu'à présent. Si je me plante: 15 heures pour recréer les images, réassemblage RAID, et je repars sur une autre stratégie corrective. Ce sera long, mais il suffit seulement de patience, les disques durs physiques, eux, sont au chaud. Ils ne craignent rien...
(10) Round 5: actions en écriture...
- C'est parti...
- Je commence par exécuter ce que j'ai rêvé de faire pendant plusieurs mois: lancer e2fsck non plus en simple diagnostic, mais laisser l'outil faire les réparations si possible manuellement afin de limiter les actions au strict minimum.
(a) Petit diagnostic de base: sudo e2fsck -n /dev/md0
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Les descripteurs de groupe semblent en mauvais état... tentons d'utiliser les blocs de sauvetage...
le superbloc a un journal invalide (i-noeud 8).
Effacer ? non
e2fsck: Illegal inode number lors de la vérification du journal ext3 pour /dev/md0
- Conclusion: ce diagnostic semble cohérent avec les autres problèmes reportés ci-dessus.
Ce qui est intéressant, c'est que ce que rapport indique que mon RAID sera formaté en EXT3 puisqu'il cherche un journal. Je me trompe ou pas? Si je ne me trompe pas, et si je parviens à récupérer mon système de fichier intact (que de si...), alors il reste un espoir que je puisse récupérer mon script effacé...??
(b) Tentative de réparation manuelle: infaisable...
- Commande
e2fsck -p /dev/md0
- Ca ne va pas: la commande me demande de modifier noeud après noeud manuellement. Il y en a pour des années, car le nombre de noeuds à réparer se compte en millions!!!.... Si je réponds non rien n'est modifié, et toutes les 3 questions, e2fsck m'informe que si je réponds oui, il y a un risque de destruction important des données. Bref: situation Cornélienne...
- Mon intuition: si autant de noeuds sont à réparer, c'est que la seule façon de réparer le système de fichier doit passer par une autre solution que e2fsck. Par exemple, testdisk ou autre utilitaire. Mais ce qui doit être entrepris dans la suite, fait partie de l'aide concrête que je vous demande....
(c) Tentative de réparation automatique:
- En début de semaine je lance la commande:
fsck -y /dev/md0
- Je lance cette commande car je veux en avoir le coeur net: je veux laisser e2fsck faire ce qu'il veut au moins une fois en automatique. Mais je me doute qu'en répondant "oui" automatiquement, il y a bien peu de chances pour qu'il en sorte quelque chose de correct. Après tout, un peu de bon sens: le fond du fond c'est que le système ne voit pas de table de partition. Comment e2fsck pourrait-il réparer des noeuds correctement s'il ne sait pas à quoi ces noeuds correspondent... C'est clair pour vous? Bon, moi, j'me comprends en tout cas...
- Résultat: e2fsck a tourné toute la nuit. 100% de CPU utilisé. Un truc de fou. Le disque dur 2To a chanté. Au petit matin, l'opération est terminée avec une suite infinie de logs de réparation / suppression de noeuds... bref.... impossible de reproduire toute ou partie de ce logs.
- Fébrillement (et sans grande illusion) je tape:
sudo mount /dev/md0 /home/moije/raid
- Ca plante encore, avec un message d'erreur que j'ai oublié de noter (désolé). Ce que je sais, c'est que le message n'était plus le message d'erreur mount habituel. Ce qui m'a incité à relancer la correction e2fsck pour une seconde passe...
- Donc, je tape une deuxième fois:
fsck -y /dev/md0
- Là, e2fsck tourne à nouveau, pendant une durée assez courte, peut-être une demi-heure, une heure max.
- e2fsck me rend la main. Je retente un mount. Ca marche!!!
- Je tape frénétiquement:
cd /home/moije/raid
,
suivi d'un pauvre
ls
- Et là: rien, que dalle, vide, niente, nada, nichts, peau'd'zobe... rien donc, à part le dossier /Lost+Found rempli d'un nombre gigantesque de dossier dont les noms sont numéros. Je suppose qu'il doit s'agir des noeuds réparés et qui ont été détectés puis réalloués comme des dossiers.
- A tout hasard je tape:
ls -R
afin de voir si certains de ces dossiers contiendraient ne serait-ce que quelques fichiers.
- Résultat: rien, que dalle, nada, etc... Tous les dossiers sont vides comme on pouvait le craindre après une telle opération de réparation en deux passes.
- Conclusion: e2fsck a bien essayé de réparer quelque chose, le seul problème, c'est juste que e2fsck ne comprend pas du tout ce qu'il répare!!!
- Conclusion de conclusion: mouais.... comme je l'ai dit, fallait tenter le coup. C'est fait. Maintenant, il faut passer à autre chose.
(d) Les étapes suivantes: à venir ? Help wanted!!!
- Me reste-t-il un espoir? J'ai bien quelques idées sur ce qu'il faudrait utiliser mais là je touche au fond de ce que je crois maîtriser et j'ai donc besoin d'aide...
** PISTE 1:
Une première piste serait d'exploiter une réparation en utilisant les superblocks de remplacement. Mais sont-ils seulement disponibles? Afin de préparer le terrain, j'ai lancé une simulation de création de système de fichier EXT3 avec la commande
mkfs -n /dev/md0.
J'obtiens:
mke2fs 1.41.9 (22-Aug-2009)
Etiquette de systeme de fichiers=
Type de systeme d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
97632256 i-noeuds, 390515264 blocs
19525763 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=0
11918 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Et à partir de là? J'ai effectivement une liste de superblocs de secours. Je sais qu'il y a un calcul bête comme chou (une multiplication je crois, numéro du superbloc x taille d'un block en Ko?) à effectuer pour indiquer l'offset d'un superbloc de secours, mais vraiment, cela m'aiderait beaucoup si quelqu'un pouvait me porter assistance sur cette piste.... Si ça rate, pas de regrets ni d'angoisse: je vous rappelle qu'il s'agit seulement d'images disques... On peut les regénérer en 15 heures ;-)
** PISTE 2:
- Je suppose que mon dernier recours sera l'outil testdisk. Mais quand (si) on doit envisager cette piste, je suppose que là encore, une âme charitable me prêtera assistance.
(11) SYNTHESE DE LA SITUATION:
- 4 disques durs de 470 Go montés en RAID-0 dans un NAS Thecus N4100, soit une capacité exploitable d'env 1.6 To
- Disques extraits du Thécus pour effectuer la récupération d'un fichier effacé par erreur (avec PhotoRec), en les remontant sous Linux.
- Impossible de remonter les disques en RAID sous Linux.
- Après de nombreux essais, le RAID peut être réassemblé avec succès, mais le système de fichier ne peut pas être remonté.
- Les deux diagnostics qui remontent sont:
* Le disque /dev/md0 n'a pas de table de partition valide
* Dans messages.log: le système EXT2 a des descripteurs de groupe corrompus.
- Impossible également de remonter les disques dans leur NAS d'origine.
- Stratégie: création de 4 images disques montées en loopback, puis assemblage RAID des 4 images afin d'effectuer des corrections en écriture sur ces disques.
- La correction e2fsck n'a rien donné.
- J'envisage la piste de réparation de la table de partition à l'aide des superblocs de secours. Mais j'ai besoin d'aide pour cette solution
- Si la solution précédente ne fonctionne pas, j'envisage la piste testdisk en dernier recours. Mais là aussi, j'aurai besoin de votre aide...
- Evidemment, toute autre solution / analyse et/ou diagnostic de votre part est bienvenu(e)...
Merci de votre aide précieuse.
