[Linux] Raid soft

Le
JKB
Bonjour à tous,

Je viens de changer un disque dans une grappe raid6 et j'ai un petit
problème de superbloc qui fait que la grappe ne monte pas
automatiquement lors du démarrage du serveur.

Root rayleigh:[~] > cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md7 : active raid6 sdc1[0] sdi1[6] sdh1[5] sdg1[4] sdf1[3] sdd1[1]
359011840 blocks level 6, 64k chunk, algorithm 2 [7/6] [UU_UUUU]

sde m'a fait des misères et je l'ai changé. Même partitionnement que
les autres (une seule partition de 73 Go), commençant au même
endroit que les autres et terminant exactement sur le même cylindre.
Tous les disques proviennent du même fabricant et sont parfaitement
identiques.

Un examen des superblocs m'indique :

Root rayleigh:[/etc/mdadm] > mdadm --examine /dev/sdc
/dev/sdc:
MBR Magic : 55aa
Partition[0] : 143637102 sectors at 63 (type fd)

-> normal, le raid est sur sdc1

Root rayleigh:[/etc/mdadm] > mdadm --examine /dev/sdc1

Version : 0.90.00

Creation Time : Sun Dec 17 16:56:20 2006


Dès que j'ajoute /dev/sde1 par mdadm -a /dev/md7 /dev/sde1,
je me retrouve avec un supebloc à la fois sur /dev/sde et sur
/dev/sde1 (!). Cela semble même être le même puisque dès que je vire
le superbloc de /dev/sde, celui de /dev/sde1 disparaît aussi.

Pourtant, je disque sde est partitionné comme suit (et comme tous
les autres) :

Root rayleigh:[/etc/mdadm] > fdisk /dev/sde

Command (m for help): p

Disk /dev/sde: 73.5 GB, 73543163904 bytes
255 heads, 63 sectors/track, 8941 cylinders, total 143638992 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 63 143637164 71818551 fd Linux raid autodetect

Problème : lors du boot, le truc me détecte que /dev/sde et
/dev/sde1 ont des superblocs très proches (tu m'étonnes) et refuse
de le monter me rendant la main avec l'horripilant prompt root pour
remettre d'équerre le système.

Étant borné, j'ai fait un dd de /dev/sdc sur /dev/sde histoire
d'être vraiment sûr que ce partitionnement est identique en tout
point. J'ai vérifié les superblocs, rien à dire, mais dès que je
remonte /dev/sde1 dans la grappe, j'ai de nouveau ce @à#~{@{ de
superbloc à la fois sur /dev/sde et sur /dev/sde1 !

Y a-t-il une solution ? Je viens de googliser toute la soirée sans
rien trouver J'ai naturellement essayer les classiques
--zero-superbloc. Rien n'y fait. La machine fautive est une sparc64
tournant sous Debian/testing.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse
=> http://grincheux.de-charybde-en-scylla.fr
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
NiKo
Le #24090531
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,



Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').



PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?

--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !

SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !
JKB
Le #24090761
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,



Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').



PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?



Merci pour ces liens que je ne connaissais pas. Je veux bien écrire
mdadm -a /dev/md7 /dev/sde1 pour ajouter le disque à la grappe
existante.

J'ai essayé d'utiliser la technique indiquée dans le second papier
pour virer le superbloc autoritairement. Rien n'y fait, dès que je
rajouter /dev/sde1 à la grappe, je me retrouve avec un superbloc sur
/dev/sde et sur /dev/sde1 !

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
JKB
Le #24091671
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,



Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').



PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?



Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
NiKo
Le #24092611
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,



Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').



PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?



Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.

Cordialement,

JKB




Ah tiens, je ne savais pas cela.

Si tu trouves la méthode pour migrer vers un raid v1.x, je serais
intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le
problème se posera lors de la prochaine 'upgrade' de Debian.

Merci

--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !

SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !
Toxico Nimbus
Le #24092841
C'est-y pas plutôt
mdadm /dev/md7 -a /dev/sde
?
Toxico Nimbus
Le #24092831
On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus
C'est-y pas plutôt
mdadm /dev/md7 -a /dev/sde



Oups ! Il fallait lire /dev/sde1 biensûr
Toxico Nimbus
Le #24093461
On Mon, 19 Dec 2011 23:18:09 +0000 (UTC), JKB
Bonjour à tous,


Je viens de changer un disque dans une grappe raid6 et j'ai un


petit
problème de superbloc qui fait que la grappe ne monte pas
automatiquement lors du démarrage du serveur.



[SNIP]


Y a-t-il une solution ? Je viens de googliser toute la soirée sans
rien trouver... J'ai naturellement essayer les classiques
--zero-superbloc. Rien n'y fait. La machine fautive est une sparc64
tournant sous Debian/testing.



Si tu ne grub pas dessus, as-tu essayé de passer en metadata 1.2 ?

Genre zero-superblock suivi d'un create -e 1.2 (éventuellement avec
--assume-clean et une prière à la divinité de ton choix).
JKB
Le #24093781
Le Tue, 20 Dec 2011 18:13:02 +0100,
NiKo
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,



Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').



PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?



Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.

Cordialement,

JKB




Ah tiens, je ne savais pas cela.

Si tu trouves la méthode pour migrer vers un raid v1.x, je serais
intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le
problème se posera lors de la prochaine 'upgrade' de Debian.



On m'a renvoyé sur les archives de la mailing list. Je suis en train
de dépouiller...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
JKB
Le #24093761
Le Tue, 20 Dec 2011 19:00:54 +0100,
Toxico Nimbus
On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus
C'est-y pas plutôt
mdadm /dev/md7 -a /dev/sde



Oups ! Il fallait lire /dev/sde1 biensûr



Ça fonctionne aussi dans l'autre sens. Le problème est un bug de mdadm
qui ne sera pas corrigé (dixit les membres causant sur la liste raid du
noyau linux).

JKB


--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
JKB
Le #24093941
Le Tue, 20 Dec 2011 22:06:51 +0000 (UTC),
JKB
Le Tue, 20 Dec 2011 18:13:02 +0100,
NiKo
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,



Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').



PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?



Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.

Cordialement,

JKB




Ah tiens, je ne savais pas cela.

Si tu trouves la méthode pour migrer vers un raid v1.x, je serais
intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le
problème se posera lors de la prochaine 'upgrade' de Debian.



On m'a renvoyé sur les archives de la mailing list. Je suis en train
de dépouiller...




Bon, le problème est relativement simple. Après avoir créé la
partition sur le nouveau disque, il faut appeler blockdev --rereadpt
/dev/sde sous peine de se voir réattribuer le même superblock sur
/dev/sde (au lieu de /dev/sde1) car l'ancienne partition était
toujours en mémoire dans les tables du noyau...

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme