Reprise du message précédent :
C'est pas un pb le nommage des disques.
 
Par contre l'ordre est ULTRA important vu qu'on va réécrire de façon arbitraire les superblock, la moindre erreur dans l'ordo et tu perds TOUT, d'où mon insistance sur ce point. Tout l'algo de distribution des parités et des données repose sur l'ordre. En temps normal, les disques ont une num inerne, ce qui ne pose pas de pb. Là on est dans le cas où on indique arbitrairement la numérotation des disques, donc l'ordre est primordial et surtout il faut le gérer manuellement tant que tes disques n'auront pas un nouveau jeu de superblock.
 
Les 4 grosses info pour remonté un raid cassé :
 
-Le type de raid bien sûr
-L'ordre des disques (inversion = foutu), on va le retrouver t'inquiète pas pour ça, j'ai déjà reconstitué les pièces du puzzle avec les infos que tu m'a filé.
-Le chunk size (mauvaise taille = foutu), info déjà connue : 64K
-l'algo de distribution des parités et données (2 méthodes de distribution des parités, 2 méthodes de distribution des données, ça fait 4 combinaisons en tout, mauvais algo = foutu), info déjà connue : left-symmetric
 
La sortie de ton mdadm --examine n'est pas complète,il manque le plus important : la ligne "this" qui est le point de repère pour chaque disque (et oui vu que les noms peuvent changer (d'ailleurs c'est le cas là), je me base pour l'ordre uniquement sur la numérotation absolue dans le raid et jamais sur le nom  du fichier de block du disque).
 
La 2eme info la plus importante, c'est la ligne "event" qui permet de savoir dans quel ordre les disques ont été sortis du raid, ce qui permet donc d'éjecter d'office le premier disque à avoir foiré chronologiquement, ce qui permet d'être tranquile lors de la reformation du raid. Comme tu as 3 disques sur 4 avec un event à 126, même pas peur    
 
Le seul truc que je ne pige pas dans l'ordre : tu as changé les disques de chassis ? Ou juste rebranchés en vrac ?  
 
 
parceque sinon la soluce la plus simple c'est encore de se contenter de faire un ordonancement logique sans se préoccuper du matos, mais il me faut une sortie mdadm -E complète de tous les disques pour ça, tu en as déjà posté une mais je ne sais pas si tu as apporté des modif' dans tes branchements de disques.
 
 
J'ai fait des cassages de raid très sale ce WE, vraiment TRES sales, à chaud, avec de l'écriture en court et des erreurs d' I/O en prime, j'ai tout remonté, et ça marche, j'ai réussi à chaque tenta, bon le système de fichier à été bien poutré par moment mais fsck à réussi à le rafistoler à chaque fois

En fait j'ai un chassis en metal qui contient 3 disques, et un 4ème qui est tout seul vissé au boitier..
C'est un peu à l'arrache en attendant mieux..
 
Je n'ai pas changé l'ordre dans le chassis par contre il est super possible que j'ai changé les branchements !
(je ferais super gaffe avec ca maintenant !)
 
merci pour ta réponse !
 
Voilà sortie de mdadm, je ne changerais plus les branchements

ok, je vais regarder un dernier truc: il est possible de mettre un raid en lecture seulle avec md (mais j'avoue que ce genre d'option ne me sert jamais), donc je vais voir s'il est possible de le mettre en ro dès la créatiton dégradée, ça évitera toute corruption en cas d'erreur de numérotation, le temps de voir si tu peux monter le volume en RO et que tu peux accéder aux données
 
 
EDIT
 
maintenant le truc, c'est de savoir comment as-tu organisé l'intérieur de ton raid ? un fs (ext3 ?) écrit en direct, une structure avec lvm ?
 
ça permettrait d'éviter les suprises
 
 
pour le moment, tu peux déjà faire ceci pour recréer les superblock et passer instantanément le raid en lecture seulle :
 

 
ensuite tu fais un fsck (vérif forcée et en lecture seulle), bref un fsck.ext3 -fn /dev/md0 si tu es en ext3 écrit en direct sur md0 pour vérifier qu'il n'y a pas de corruption du fs
 
pour repasser le raid en rw :
 

 
puis remonter le volume, attention en ext3 des fois j'ai eu des merdes avec le journal, le mieux est encore de faire un montage en lecture seulle et en tant que ext2:
 

 
dès que les données sont à nouveau accessible, tu peux immediatement lancer le rebuild du raid5 :
 

 
et comme le rebuild va ralentir à mort le système si tu veux encore taper des commandes sans avoir l'impression que ça rame :
 

 
et enfin, tu peux soit faire la récup' de tes données sur un gros disque externe, soit tenter de réparer le fs, là après ça dépend, mais genre tu démontes, tu reconstruit un journl si il a été pété (tune2fs -j /dev/md0), et autre trucs du genre, pour le moment je suis sûr pour le raid, moins pour l'état du fs. Le pb étant que c'est un très gros fs donc impossible de le répliquer facilement sur d'autres disques
 
une fois que le raid aura été refait, les pb qui peuvent persister avec ext3 sont les suivants :
 
-pb avec le journal (résolu en supprimant le journal, fsck puis recréation de journal et remontage)
-pb avec le LABEL (résolu en supprimant le label/rebootant/refaire le label) je suis un gros utilisateur de label (RHEL et centos style) donc c'est pout ça que je précise ce point qui m'a posé pb à plusieurs reprises, là idem, j'ai eu des pb de LABEL avec jfs et reiserfs aussi

Cool, je vais tester ca ce soir
 
Sur mon raid, c'est du ext3 direct.
 
Je donne des news dès que je commence...
 

Bon je suis pas encore chez moi mais j'ai pris 5min pour lire ton post (mes commentaires en gras ci-dessous)
 

 
Tks a lot !

Je suis chez moi, j'essaye de comprendre la logique du create.
 
Pour moi on a :
 
device actuel - device avant - number - state
 

 
si je fais la correspondance avec ta commande create :

 
du coup je pige pas la logique.. et j'aimerais bien pour bien comprendre et ré-iterer ce genre d'exploits dans le futur
 
tu vois ce que je veux dire ?
 
Sinon, j'ai exécuté (en annulant lorsque mdadm me demande la confirmation) et la commande  
 

donne le msg d'erreur suivant :

est-ce normal ? (création non effectuée donc possible que oui)
 
Merci !

possible en effet : le -o permet le passage d'une grappe en lecture seulle, après le truc vient peut-être de la version de mdadm incorporée à deb' 6 sachant que j'ai fait mes tests sur du centos 5
 
en fait ma logique : retrouver la num interne de tes disques  (ligne "this", je ne regarde même pas comment les disques se voient entre eux relativement, étant donné que c'est justement de là que vient le pb, ce qui sera affiché sera de toutes façons erroné, mais seullement leur numérotation absolue qui est la seulle bonne info dans tout ça) et si les données sont à jour ou pas (un des disque ne l'est pas, ligne "event" ). après je suis parti du principe que le disque #4 (qui n'est pas censé exister) était le disque #0 en état removed et repassé en spare (par je ne sais quel miracle), les autres étants coérents.
 
Au pire, même si tu reconstruit ta grappe dégradée de travers, il n'y a aucun risque perte de données tant que :
-tu n'écris rien sur md0 (absolument aucune opé d'écriture)
-tant que tu ne réintègres pas le dernier disque (ce aurait pour conséquence de lancer un rebuild et va écraser des données existantes à récupérer avec des parités en cas d'erreur)
 
sion pas de soucils pour le fs en ext3 (disons que je n'utilises jamais ext3 pour du stockage, chez moi c'est à fond XFS \o/), et ouais faire un fsck avec le raid en rw, par sécu un fsck.ext3 -n préliminaire qui n'apporte pas de changement au fs même en cas d'erreur, ça permet déjà de savoir si le fs est intègre ou non avant de tenter un montage

Ok.
 
Je tente quand je serais de nouveau a la maison.
 
Je m'inquiete pas mal de ce qui a pu se passer quand j'ai installé tout ca sur une conf pourrie.. bon on verra bien
 
Merci en tout cas!

Bon je viens de tester le mdadm create ; fsck.ext3 n'est pas d'accord
 

 
Si j'ai suivi, ça veut dire qu'il faut tester avec un autre ordre, genre

Puis

...
Jusqu’à ce que fsck soit d'accord ?
 
Je confirme que la commande de read only n'est pas acceptée par mdadm dans ce mode
(pourtant elle est présente dans le man)

Ah et ya moyen de défaite le raid ?
Il rale quand j'essaye avec une autre combinaison ..

mdadm --stop /dev/md0, n'essayes pas de bouger l'ordre de missing, la combinaison ne doit pas être bonne, j'espère surtout que le disque marqué en spare ne va pas poser de pb.
 
pour le moment, il faut faire un --stop avant de réarranger la grappe, et puis bon, des cat /proc/mdstat pour surveiller  
 
à mon avis, tu n'a pas du défaire la grappe telle qu'elle était reconnue avant de lancer le fsck, ce qui explique l'erreur.
 
bref, pour le moment tu repart là dessus :
 

 
par la logique, je ne vois pas quel autre ordre on pourrait avoir, essayes déjà ceci avant de tenter autre chose.

La création de la grappe fonctionne :

 
mais malheuresement fsck ne considère pas le fs valide..

ok, donc efectivement il va y avoir plusieurs combinaisons à tester  
 
je vais essayer de la classer par num de version minor de périph' block, ce qui donne :
 

 
j'ai regardé, en fait ça semble plus logique (ça correspond bien à l'équivalent de /dev/sd[a-c]1 missing sur ton ancienne machine, donc c'est mieux barré   )
 
un conseil : si jamais il y a encore des test de reconstruction à faire, je te conseilles de faire un --stop juste après un échec au fsck    
mais avec cette séquence là ça me paraît bien mieux barré qu'avec la première

Ca va être drôle

donc mouaip à priori y'avait 2 disques d'inversés dans ma toute première commande \o/

c'est à a dire ?
 
ca fait bcp de combaison mais y'a ptet moyen d'optimiser..
 
un script sinon ?
 
j'avais pas vu ton edit
 
j'essaye

non, y'a pas 36 combinaisons, essayes déjà avec /dev/sd[c-e]1 missing
 
à priori, on a 24 combinaisons possibles
 
bon, je restes encore quelques minutes, après il faut que j'aille dégarnir une portière de ma bagnole  

marche pô
 
bon...

merci
bon je sens que je vais faire un script

 
passage de cable ? vitre qui ferme plus ?

T'as déjà essayé ça ?
https://raid.wiki.kernel.org/index.php/Permute_array.pl

ou alors y'a eu une merdouille au passage d'un des disques en spare, et là ce serait la merde, il faudrait réintégrer ton actuel sdb dans la séquence et virer ton actuel sdc.
 
Tu peux toujours essayer ton script, mais je ne sais pas s'il est prévu pour fonctionner sur un raid qui n'a pas ses superblock d'origine
 
D'ailleurs, le script ne prend même pas en charge les différents algo de distrib' des parités  
un point à améliorer donc (j'aime bien le right asymmetric, plus perf' que le left-symmetric en écriture)    

Ca craint d'essayer sdc = missing au lieu de sdb = missing ?

bah ça craint rien tant que tu ne fais pas d'opé d'écriture sur md0
dans tous les cas il faut changer l'ordre de toutes façons
 
parceque niveau combinaisons, si on prend en compte le nb de combi possible avec un missing, ça donne 96 combinaisons au total  

 
Dans notre cas on sait que c'est du ls deja
 
risqué de faire du mount au lieu de fsck (comme le fait le script ?)

 
Effectivement, je viens de lancer le script en mode test et c'est le nombre de combinaisons testées...
 
bon je me lance  

Ca ne donne pas de résultat...
 
Et mer....
 
(j'ai modifié le script pour passer le --chunk=64 et --layout=ls)
 
Je crois que je vais finir par me résoudre à la perte de mes données...

Qu'en pense tu? C'est cuit ?

J'ai l'impression que c'est le passage de ton disque en spare pendant un temps qui pose pb en fait, parceque je n'ai pas réussi à reproduire ce comportement là avec md
 
 
Sinon, il teste à voir si des soft comme raid reconstructor fonctionnent avec md, ça me paraît bien possible. A voir donc

Je vais laisser ces disques de coté et monter une nouvelle grappe avec de nouveaux disques (4x 2To)
 
J'y mettrais mes backups (partiels, hélas)
 
La pour l'instant j'en ai marre de galérer
 
Du coup si tu as des conseils sur la création d'un nouveau raid tout neuf je suis preneur !

mouaip, c'est le bordel ton affaire quand même ^^"
 
Pour la gestion des raid, voilà comment je m'y prends (déformation professionnelle aussi):
 
-Je stocke les données sur un NAS avec du raid5
-Je fais des backup différentiels réguliers du NAS
-Mes grappes raid sont toutes numérotés, et même avant que je soit un maniac du dymo, je m'arrangeais toujours pour classer mes disques dans un ordre logique (par numéro de série croissant par exemple) vissé/rackés dans l'ordre dans le chassis, branchés dans l'ordre sur le contrôleur/la mobo, reconnus dans l'ordre dans l'OS, etc.... bref tout est fait pour ne jamais se planter, même si l'ordre ne joue pas quand tout fonctionne, ça devient vite galère au premier pépin comme tu as pu le constater
 
Pour la création du raid (surtout les raid5), si tu compte continuer sur md, voilà d'autres points :
 
-toujours créer un journal (bitmap interne), option --bitmap=internal (ça marche au --create et au --grow)
-essayer différents algo de distribution, pour l'instant j'ai toujours eu de meilleurs résultats avec --layout=ra (right asymmetric : les partiés progressent vers la "droite" (du premier vers le dernier disque à chaque nouvelle série de bandes) et une nouvelle série de bandes de données repart sur le premier disque)
-essayer avec differents chunk size, quand tu as un NAS dédié au stockage, tu peux te permettre de diminuer le chunk size (ça augemente pas trop mal les débits), ça augmentera la charge CPU mais c'est pas bien grave vu qu'il est justement là pour ça
-Ne pas hésiter à éventuellement découper un raid md avec lvm2 si besoin.
-Essayer d'autres fs que ext3 qui est finalement peu performant, tu aura de bien meilleurs résultats avec reiserfs sur les petites fichiers et avec XFS et JFS sur les gros fichiers, quant aux arborescences énormes avec plusieurs millions de fichiers, là ya pas photo : XFS direct
 
-toujours avoir un bon bloc d'alim (mais bon, c'est déjà ton cas), il ne faut jamais rogner sur la qualité des blocs d'alim, une noname c'est traître
-je recommande très vivement d'avoir un ondulo pour le NAS, assez puissant pour tenir 20 minutes
-avec les disques : idem, prendre des disques prévus pour le 24/7 si possible, perso j'ai des WD RE3 pour mes données (maintenant ce sont les RE4 les nouveaux), c'est disques sont plus cher que des caviar black (en fait ce sont des caviar black à firm modifié et qui subbissent un test de torture de 36 à 48H avant conditionnement, tout comme les disques SCSI ou SAS) mais leur garantie est de 5 ans, ces disques sont vraiment excellents mais demandent forcément un gros budget vu que c'est des disques SATA de serveur. Sinon tu as aussi les disques prévu pour un usage en videosurveillance qui sont moins cher et probablement tout aussi bien et prévus pour être très solicités mais avec une garantie de 3 ans : http://www.ldlc.com/fiche/PB00109952.html Dans tous les cas, comme pour l'alim, il ne faut jamais rogner sur la qualité des disques, et il faut éviter de se laisser séduire pour les prix attractifs des samsung, ces disques sont performants et pas chers, mais dans les faits les taux de pannes sont vraiment énormes, bref tu peux tirer une croix sur tous les samsung en technologie PMR parceque si tu fais du raid5 avec tu va devoir les acheter par palettes entières
Idem, je ne recommanderais pas seagate (sauf dans les gammes pro : constellation, cheetah, savvio), je peux te dire que regarder les valeurs smart d'un barracuda ça fout des grosses frayeurs des fois  

Merci pour tout ces conseils et aussi pour l'aide précieuse que tu m'as apportée.
 
La perte de données est relou, mais c'est aussi une lecon (et j'ai des backup du plus important.. enfin presque )
 
Je vais monter un raid 5 3x 2To selon tes recommandations
(bitmap et tout)
 
J'ai déjà un onduleur (eaton 650), j'avais programmé le démontage de la grappe raid après 5min et l'extinction du pc au bout de 10m pour éviter tout arrêt violent
Niveau alim, j'ai opté pour une seasonic 430
 
Par contre pour les disques la solution RE4 est un peu trop chere pour moi, les AV GP ont l'air très bien mais ils ne sont pas dispos partout !
 
Donc je sais pas... Attendre ?
Caviar Green ?