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.
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.
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
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...
Curieux, normalement les outils de patitionnement devraient recharger la table de partition du disque automatiquement après l'avoir modifiée, sauf si une partition du disque est en cours d'utilisation. Mais dans ce cas blockdev --rereadpt ne marchera pas non plus.
Concernant le problème, ça me dit quelque chose. C'est dû au fait que le superbloc 0.9 est en fin de volume. Si la fin de la dernière partition coïncide avec la fin du disque, alors les deux peuvent être vus comme ayant un superbloc. Peut-être que spécifier "DEVICE /dev/sd??*" dans mdadm.conf peut aider en forçant mdadm à rechercher un superbloc sur les partitions seulement.
Salut,
JKB a écrit :
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...
Curieux, normalement les outils de patitionnement devraient recharger la
table de partition du disque automatiquement après l'avoir modifiée,
sauf si une partition du disque est en cours d'utilisation. Mais dans ce
cas blockdev --rereadpt ne marchera pas non plus.
Concernant le problème, ça me dit quelque chose. C'est dû au fait que le
superbloc 0.9 est en fin de volume. Si la fin de la dernière partition
coïncide avec la fin du disque, alors les deux peuvent être vus comme
ayant un superbloc. Peut-être que spécifier "DEVICE /dev/sd??*" dans
mdadm.conf peut aider en forçant mdadm à rechercher un superbloc sur les
partitions seulement.
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...
Curieux, normalement les outils de patitionnement devraient recharger la table de partition du disque automatiquement après l'avoir modifiée, sauf si une partition du disque est en cours d'utilisation. Mais dans ce cas blockdev --rereadpt ne marchera pas non plus.
Concernant le problème, ça me dit quelque chose. C'est dû au fait que le superbloc 0.9 est en fin de volume. Si la fin de la dernière partition coïncide avec la fin du disque, alors les deux peuvent être vus comme ayant un superbloc. Peut-être que spécifier "DEVICE /dev/sd??*" dans mdadm.conf peut aider en forçant mdadm à rechercher un superbloc sur les partitions seulement.
Toxico Nimbus
On Tue, 20 Dec 2011 22:11:57 +0000 (UTC), JKB wrote:
Le Tue, 20 Dec 2011 19:00:54 +0100, Toxico Nimbus écrivait : > On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus > wrote: >> 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.
OK, je ne savais pas.
Le problème est un bug de mdadm qui ne sera pas corrigé (dixit les membres causant sur la liste
raid du
noyau linux).
C'est donc une feature. Si tu trouves un workaround, pour ma culture personnelle, je suis intéressé.
On Tue, 20 Dec 2011 22:11:57 +0000 (UTC), JKB
<jkb@koenigsberg.invalid> wrote:
Le Tue, 20 Dec 2011 19:00:54 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
> On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus
><tox.nimbus@gmail.com> wrote:
>> 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.
OK, je ne savais pas.
Le problème est un bug de mdadm
qui ne sera pas corrigé (dixit les membres causant sur la liste
raid du
noyau linux).
C'est donc une feature. Si tu trouves un workaround, pour
ma culture personnelle, je suis intéressé.
On Tue, 20 Dec 2011 22:11:57 +0000 (UTC), JKB wrote:
Le Tue, 20 Dec 2011 19:00:54 +0100, Toxico Nimbus écrivait : > On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus > wrote: >> 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.
OK, je ne savais pas.
Le problème est un bug de mdadm qui ne sera pas corrigé (dixit les membres causant sur la liste
raid du
noyau linux).
C'est donc une feature. Si tu trouves un workaround, pour ma culture personnelle, je suis intéressé.
JKB
Le Wed, 21 Dec 2011 10:17:15 +0100, Toxico Nimbus écrivait :
On Tue, 20 Dec 2011 22:11:57 +0000 (UTC), JKB wrote:
Le Tue, 20 Dec 2011 19:00:54 +0100, Toxico Nimbus écrivait : > On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus > wrote: >> 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.
OK, je ne savais pas.
Le problème est un bug de mdadm qui ne sera pas corrigé (dixit les membres causant sur la liste
raid du
noyau linux).
C'est donc une feature. Si tu trouves un workaround, pour ma culture personnelle, je suis intéressé.
Voir sur fr.comp.stockage. Il faut au moment de la réintroduction du nouveau disque forcer le noyau à prendre en compte la nouvelle partition. Comme le volume explosait en vol, il virait le disque neuf du volume pour le relancer mais ne mettait pas à jour la table des partitions dans les tables du noyau. Il suffisait de recréer une partition identique aux autres et de forcer un blockdev avec l'option qui va bien pour forcer la lecture de la nouvelle partition histoire que le module raid456 ne se marche pas sur les pieds.
En forçant à la main l'introduction du nouveau disque dans la grappe, j'entretenais le problème puisqu'au nouveau boot je me retrouvais avec le même superblock sur le disque et la partition. En fait, une manière de faire aurait été de redémarrer deux fois le serveur avec effacement du superblock fautif entre les deux pour forcer la relecture des tables.
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
Le Wed, 21 Dec 2011 10:17:15 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
On Tue, 20 Dec 2011 22:11:57 +0000 (UTC), JKB
<jkb@koenigsberg.invalid> wrote:
Le Tue, 20 Dec 2011 19:00:54 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
> On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus
><tox.nimbus@gmail.com> wrote:
>> 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.
OK, je ne savais pas.
Le problème est un bug de mdadm
qui ne sera pas corrigé (dixit les membres causant sur la liste
raid du
noyau linux).
C'est donc une feature. Si tu trouves un workaround, pour
ma culture personnelle, je suis intéressé.
Voir sur fr.comp.stockage. Il faut au moment de la réintroduction du
nouveau disque forcer le noyau à prendre en compte la nouvelle
partition. Comme le volume explosait en vol, il virait le disque
neuf du volume pour le relancer mais ne mettait pas à jour la table
des partitions dans les tables du noyau. Il suffisait de recréer une
partition identique aux autres et de forcer un blockdev avec
l'option qui va bien pour forcer la lecture de la nouvelle partition
histoire que le module raid456 ne se marche pas sur les pieds.
En forçant à la main l'introduction du nouveau disque dans la
grappe, j'entretenais le problème puisqu'au nouveau boot je me
retrouvais avec le même superblock sur le disque et la partition. En
fait, une manière de faire aurait été de redémarrer deux fois le
serveur avec effacement du superblock fautif entre les deux pour forcer
la relecture des tables.
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
Le Wed, 21 Dec 2011 10:17:15 +0100, Toxico Nimbus écrivait :
On Tue, 20 Dec 2011 22:11:57 +0000 (UTC), JKB wrote:
Le Tue, 20 Dec 2011 19:00:54 +0100, Toxico Nimbus écrivait : > On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus > wrote: >> 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.
OK, je ne savais pas.
Le problème est un bug de mdadm qui ne sera pas corrigé (dixit les membres causant sur la liste
raid du
noyau linux).
C'est donc une feature. Si tu trouves un workaround, pour ma culture personnelle, je suis intéressé.
Voir sur fr.comp.stockage. Il faut au moment de la réintroduction du nouveau disque forcer le noyau à prendre en compte la nouvelle partition. Comme le volume explosait en vol, il virait le disque neuf du volume pour le relancer mais ne mettait pas à jour la table des partitions dans les tables du noyau. Il suffisait de recréer une partition identique aux autres et de forcer un blockdev avec l'option qui va bien pour forcer la lecture de la nouvelle partition histoire que le module raid456 ne se marche pas sur les pieds.
En forçant à la main l'introduction du nouveau disque dans la grappe, j'entretenais le problème puisqu'au nouveau boot je me retrouvais avec le même superblock sur le disque et la partition. En fait, une manière de faire aurait été de redémarrer deux fois le serveur avec effacement du superblock fautif entre les deux pour forcer la relecture des tables.
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 Wed, 21 Dec 2011 09:50:11 +0100, Pascal Hambourg écrivait :
Salut,
JKB a écrit :
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...
Curieux, normalement les outils de patitionnement devraient recharger la table de partition du disque automatiquement après l'avoir modifiée, sauf si une partition du disque est en cours d'utilisation. Mais dans ce cas blockdev --rereadpt ne marchera pas non plus.
Concernant le problème, ça me dit quelque chose. C'est dû au fait que le superbloc 0.9 est en fin de volume. Si la fin de la dernière partition coïncide avec la fin du disque, alors les deux peuvent être vus comme ayant un superbloc. Peut-être que spécifier "DEVICE /dev/sd??*" dans mdadm.conf peut aider en forçant mdadm à rechercher un superbloc sur les partitions seulement.
Je ne cherche pas trop à comprendre le pourquoi du comment. Ça me semble un bug quelque part dans mdadm qui semble être confirmé sur la liste de développement du module raid.
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
Le Wed, 21 Dec 2011 09:50:11 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
Salut,
JKB a écrit :
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...
Curieux, normalement les outils de patitionnement devraient recharger la
table de partition du disque automatiquement après l'avoir modifiée,
sauf si une partition du disque est en cours d'utilisation. Mais dans ce
cas blockdev --rereadpt ne marchera pas non plus.
Concernant le problème, ça me dit quelque chose. C'est dû au fait que le
superbloc 0.9 est en fin de volume. Si la fin de la dernière partition
coïncide avec la fin du disque, alors les deux peuvent être vus comme
ayant un superbloc. Peut-être que spécifier "DEVICE /dev/sd??*" dans
mdadm.conf peut aider en forçant mdadm à rechercher un superbloc sur les
partitions seulement.
Je ne cherche pas trop à comprendre le pourquoi du comment. Ça me
semble un bug quelque part dans mdadm qui semble être confirmé sur
la liste de développement du module raid.
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
Le Wed, 21 Dec 2011 09:50:11 +0100, Pascal Hambourg écrivait :
Salut,
JKB a écrit :
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...
Curieux, normalement les outils de patitionnement devraient recharger la table de partition du disque automatiquement après l'avoir modifiée, sauf si une partition du disque est en cours d'utilisation. Mais dans ce cas blockdev --rereadpt ne marchera pas non plus.
Concernant le problème, ça me dit quelque chose. C'est dû au fait que le superbloc 0.9 est en fin de volume. Si la fin de la dernière partition coïncide avec la fin du disque, alors les deux peuvent être vus comme ayant un superbloc. Peut-être que spécifier "DEVICE /dev/sd??*" dans mdadm.conf peut aider en forçant mdadm à rechercher un superbloc sur les partitions seulement.
Je ne cherche pas trop à comprendre le pourquoi du comment. Ça me semble un bug quelque part dans mdadm qui semble être confirmé sur la liste de développement du module raid.
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
