Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian mdadm "not large enough to join array" et fdisk incohérent

mdadm "not large enough to join array" et fdisk incohérent

28 réponses
Avatar
Kevin Hinault
Bonjour =E0 tous,

J'ai deux probl=E8me qui sont li=E9s l'un =E0 l'autre :

J'ai un RAID 1 tout b=EAte (en mirroring donc) depuis quelques mois qui
tournait pas mal mais il est un peu sp=E9cial : chacun des deux disques
est chiffr=E9 avec luks et le raid contient des LVM, c'est =E0 dire un
empilement comme celui-ci :

[_ext3_____|_ext3__]
[_lvm_lv___|_lv____]
[_lvm_vg___________]
[_lvm_pv___________]
[_raid1_soft_______]
[_fd_____][_fd_____]
[_luks___][_luks___]
[_disk1__][_disk2__]

La semaine derni=E8re, un de mes disques a commencer =E0 d=E9conner (erreur=
s
d'=E9critures diverses, erreurs visible avec smartmontools et l'outil
propri=E9taire du constructeur confirmait =E7a). J'ai donc sorti ce disque
de ma grappe avec mdadm :

# mdadm --manage /dev/md0 --set-faulty /dev/dm-4
mdadm: set /dev/dm-4 faulty in /dev/md0
# mdadm --detail /dev/md0
[...blabla...]
=A0=A0=A0Number =A0=A0Major =A0=A0Minor =A0=A0RaidDevice State
=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=
=A0=A00 =A0=A0=A0=A0=A0removed
=A0=A0=A0=A0=A01 =A0=A0=A0=A0254 =A0=A0=A0=A0=A0=A0=A05 =A0=A0=A0=A0=A0=A0=
=A01 =A0=A0=A0=A0=A0active sync =A0=A0/dev/dm-5
=A0=A0=A0=A0=A02 =A0=A0=A0=A0254 =A0=A0=A0=A0=A0=A0=A04 =A0=A0=A0=A0=A0=A0=
=A0- =A0=A0=A0=A0=A0faulty spare =A0=A0/dev/dm-4

# mdadm --manage /dev/md0 --remove /dev/dm-4
mdadm: hot removed /dev/dm-4 from /dev/md0
# mdadm --detail /dev/md0
[...blabla...]
=A0=A0=A0Number =A0=A0Major =A0=A0Minor =A0=A0RaidDevice State
=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=
=A0=A00 =A0=A0=A0=A0=A0removed
=A0=A0=A0=A0=A01 =A0=A0=A0=A0254 =A0=A0=A0=A0=A0=A0=A05 =A0=A0=A0=A0=A0=A0=
=A01 =A0=A0=A0=A0=A0active sync =A0=A0/dev/dm-5


J'ai renvoy=E9 le disque au constructeur qui m'en a renvoy=E9 un neuf de
m=EAme capacit=E9 aujourd'hui.
En le recevant, j'ai refait comme j'avais fait lors de la cr=E9ation du
raid, j'ai cr=E9=E9 une partition vide (Empty, type=3D0) puis chiffr=E9
celle-ci et voulu l'int=E9grer dans le raid tout simplement :

# mdadm --manage /dev/md0 --add /dev/dm-4
mdadm: /dev/dm-4 not large enough to join array

Le message me dit que c'est un probl=E8me de taille mais si je v=E9rifie
les tailles, je ne trouve pas =E7a,=A0 au contraire je trouve une
diff=E9rence entre gnu-fdisk et fdisk

gnu-fdisk me dit =E7a :

# fdisk -l /dev/dm-4
GNU Fdisk 1.2.4
Disk /dev/dm-4: 1000 GB, 1000194048000 bytes
255 heads, 63 sectors/track, 121600 cylinders
Units =3D cylinders of 16065 * 512 =3D 8225280 bytes

# fdisk -l /dev/dm-5
GNU Fdisk 1.2.4
Disk /dev/dm-5: 1000 GB, 1000194048000 bytes
255 heads, 63 sectors/track, 121600 cylinders
Units =3D cylinders of 16065 * 512 =3D 8225280 bytes


Alors que le fdisk de base sur Debian me dit :

# /sbin/fdisk.distrib -l /dev/dm-4
Disk /dev/dm-4: 1000.2 GB, 1000201188352 bytes
255 heads, 63 sectors/track, 121600 cylinders
Units =3D cylinders of 16065 * 512 =3D 8225280 bytes

# /sbin/fdisk.distrib -l /dev/dm-5
Disk /dev/dm-5: 1000.2 GB, 1000201712640 bytes
255 heads, 63 sectors/track, 121600 cylinders
Units =3D cylinders of 16065 * 512 =3D 8225280 bytes


Mes deux questions sont :
Qui dois-je croire ?
Si c'est fidsk.distrib qui a raison, comment je peux dire =E0 mon raid
d'utiliser un disque l=E9g=E8rement plus petit ?

--
K=E9vin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/AANLkTi=StjU1UMt0upMnEa_iNaoFpjaJsOPksApSmS_A@mail.gmail.com
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
JC
On Tue, 26 Oct 2010 22:19:53 +0200
"Jean-Yves F. Barbier" wrote:

ça n'est pas une question de bug, il suffit qu'un seul bit saute au mauvais
endroit et c'est râpé (loi de Murphy oblige, ça arrive plu s souvent que
les stats ne le suppute.)
sans compter que la réunion de 2 couches "sensibles" n'entraine pas une
évolution linéaire des PBs, mais plutôt exponentielle.



Bonjour,
Moi aussi, je suis étonné d'apprendre que RAID + LVM ne font pas bon ménage.
J'utilise du RAID1 + LVM depuis 2 ou 3 ans et je n'ai jamais eu de
soucis.
Sans mettre en doute vos dire et juste pour mon information personnelle
(éventuellement avant de revenir sur du simple RAID1 logiciel), sur qu oi
se base une telle affirmation ?

Merci de vos lumières.
Cordialement.
--
Salutations.
Jean-Claude

PSYCHOLOGUE : c'est celui qui regarde les autres quand une
jolie femme entre dans une pièce.
Pierre DESPROGES

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Tue, 26 Oct 2010 22:31:59 +0200, Kevin Hinault wrote:

Hum moi c'est ce qui m'a permis de sauver mes données et de dét ecter
mon problème de disque rapidement :
la couche physique du disque était abimée, ce qui génà ©rait des erreurs
logiques dans la couche chiffrement et donc mon raid voyait des
différences entre les luks, mais je n'ai perdu aucune donnée pu isqu'il
les corrigeait.
Dans le cas d'un seul chiffrement, les erreurs logiques auraient peut
être été reportés sur les deux disques et j'aurais pe rdu mes données
puisque la structure des deux luks aurait été abimée.



alors, puisque TU SAIS, ne poses pas une question dont TU as la réponse
CQFD.

entre-parenthèses, ton raisonnement est faux puisque la couche RAID
logicielle effectue un checksum, au même titre qu'un contrôleur h ardware, et
est donc à même de détecter une disparité entre donnà ©es fournies et écrites.

--
Psychoanalysis is that mental illness for which it regards itself a therapy.
-- Karl Kraus

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Kevin Hinault
Le 26 octobre 2010 22:00, Kevin Hinault a écrit :
Le 26 octobre 2010 20:56, Sylvain L. Sauvage
a écrit :

Donc a priori il suffirait de trouver où j'ai perdu les 512ko... Piste
intéressante merci !!

Tu utilises directement /dev/sd. ou tu as fait une partition
/dev/sd.1 ?



Oui j'ai créé une partition de type primaire sur sdb donc sdb1.

Si partition, est-ce que c’est bien la même table ? (Je pense
p.ex. à une différence de taille entre une table ms-dos et une
GPT.)






Tes excellentes questions viennent de me sauver. J'ai tenté dans un
premier temps de copier la table de partition d'un disque à l'autre
pour être certain d'avoir les mêmes puis j'ai retenté un luksFormat
sur sdb1 ...
... et manque de pot je revient exactement au même chiffre sur
/dev/dm-4. A mon avis il y a eu une mise à jour de cryptsetup ou luks
depuis le début de l'année qui doit maintenant utiliser un entête plu s
grand sur le disque. (Ce n'est qu'une supposition mais je ne vois pas
d'autres possibilités).

# fdisk -l /dev/mapper/raid_disk1
Disk /dev/mapper/raid_disk1: 1000.2 GB, 1000201188352 bytes

Par contre ça m'a permis de trouver une parade, j'ai fait le
luksFormat directement sur le disque /dev/sdb

# cryptsetup luksFormat -c aes -h sha256 /dev/sdb

Et je gagne 2Mo environ.

# fdisk -l /dev/mapper/raid_disk1
Disk /dev/mapper/raid_disk1: 1000.2 GB, 1000203833344 bytes

Et donc je peux reconstruire mon array !!! :

# mdadm --manage /dev/md0 --add /dev/dm-5
mdadm: added /dev/dm-5

# mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Thu Feb 11 22:39:46 2010
Raid Level : raid1
Array Size : 976759360 (931.51 GiB 1000.20 GB)
Used Dev Size : 976759360 (931.51 GiB 1000.20 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Tue Oct 26 22:52:05 2010
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1

Rebuild Status : 0% complete

UUID : e6d41a96:ca63711a:333fb2a5:6fcb4886 (local to host loki)
Events : 0.1151744

Number Major Minor RaidDevice State
2 253 5 0 spare rebuilding /dev/dm-5
1 253 4 1 active sync /dev/dm-4


L'autre piste que j'aurais suivi ensuite aurais été de faire un dd
complet d'un disque à l'autre.

--
Kévin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/AANLkTinNmHQTtgd-aj+
Avatar
Kevin Hinault
Le 26 octobre 2010 23:05, Jean-Yves F. Barbier a écrit :
On Tue, 26 Oct 2010 22:31:59 +0200, Kevin Hinault wro te:

Hum moi c'est ce qui m'a permis de sauver mes données et de détecter
mon problème de disque rapidement :
la couche physique du disque était abimée, ce qui générait des e rreurs
logiques dans la couche chiffrement et donc mon raid voyait des
différences entre les luks, mais je n'ai perdu aucune donnée puisqu' il
les corrigeait.
Dans le cas d'un seul chiffrement, les erreurs logiques auraient peut
être été reportés sur les deux disques et j'aurais perdu mes don nées
puisque la structure des deux luks aurait été abimée.



alors, puisque TU SAIS, ne poses pas une question dont TU as la réponse
CQFD.



Je viens juste d'y songer, ce n'est pas du savoir, c'est de la
réflexion à chaud.

entre-parenthèses, ton raisonnement est faux puisque la couche RAID
logicielle effectue un checksum, au même titre qu'un contrôleur hardw are, et
est donc à même de détecter une disparité entre données fournie s et écrites.



J'ai dit "peut-être".

--
Kévin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/AANLkTimiEx1Ro9GKF+9PGg7e9rsrTg=aYoG=
Avatar
Jean-Yves F. Barbier
On Tue, 26 Oct 2010 22:30:10 +0200, JC wrote:

> ça n'est pas une question de bug, il suffit qu'un seul bit saute au
> mauvais endroit et c'est râpé (loi de Murphy oblige, ça arrive plus
> souvent que les stats ne le suppute.)
> sans compter que la réunion de 2 couches "sensibles" n'entraine pa s une
> évolution linéaire des PBs, mais plutôt exponentielle.

Bonjour,
Moi aussi, je suis étonné d'apprendre que RAID + LVM ne font pa s bon
ménage. J'utilise du RAID1 + LVM depuis 2 ou 3 ans et je n'ai jamais eu de
soucis.
Sans mettre en doute vos dire et juste pour mon information personnelle
(éventuellement avant de revenir sur du simple RAID1 logiciel), sur quoi
se base une telle affirmation ?



sur du vécu, un HD qui saute et des données irrécupérab les après
son remplacement: en fait une impossibilité de récupérer les données malgré
que le LVM ne soit pas strippé.
Un arrêt normal du système et au démarrage pouf, une erreur et plus rien...

une chose est toute fois à noter: depuis l'apparition du SATA et *surt out*
de ses connecteurs d'alim (quasiment aucune poss. de rupture de continuit é
par vibrations, contrairement aux molex semi-circulaires), le risque a pas
mal reculé (j'ai même un vieux svr avec 6 HDz qui ont des câ bles d'alim
soudés, sinon il fallait resserrer les connecteurs d'alim toutes les
semaines sous peine d'erreurs à répétition à cause des vibrations
basse-fréquences.)

sinon, pour la mathématique Murphyenne c'est simple: chaque couche a la
capacité de parasiter l'autre (DONC, elle le fera!) ce qui fait que tu
multiplies les possibilités d'échec par bien plus que le taux d'e rreur
unitaire (et si tu as un bit qui saute au mauvais endroit c'est le
(hi)jackpot)

--
In these matters the only certainty is that there is nothing certain.
-- Pliny the Elder

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Goldy
Le 26/10/2010 21:53, Kevin Hinault a écrit :

Le 26 octobre 2010 21:39, Goldy a écrit :

Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y
ait le moindre problème sur le disque, uniquement en le sortant et en le
réintégrant à l'array (raid5 + lvm + chiffrement).

Pareil en ce qui concerne le chiffrement, un seul chiffrement sur le
volume raid est suffisent, chiffrer les deux volumes est d'une
redondance inutile.



Donc tu as d'abord créé ton raid et puis tu l'a chiffré et mis du lvm
par-dessus c'est bien ça ?
C'est juste pour mon info perso et pour le futur puisque dans le cas présent




Non, c'est l'inverse. Un raid 5, LVM, et chiffrement des disques
logiques lvm. J'avais fait une mauvaise manipulation qui avait sortie un
disque de l'array, après l'avoir réintégré, LVM était incapable de
détecter les volumes logique sur le volume raid, et comme les volumes
lvm étaient chiffrés, il m'a été impossible de récupérer quoi que ce
soit dessus. Il s'agissait d'un serveur de backup sur lequel j'avais
stocké tout mon historique informatique depuis que j'avais eu un
ordinateur, ça représentait plusieurs années de tout et n'importe quoi
et ça a été dur sentimentalement de perdre tout ça. Depuis j'ai pigé la
leçon.

Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré
l'entièreté du volume avec luks, j'utilise un disque usb pour /boot.
Seul problème avec cette config, le raid6 est trop rapide par rapport
aux capacité de luks de déchiffrer les données (pas multithreadé...), et
donc une application ayant une forte sollicitation du disque (comme un
calcule sha sur un gros fichier par exemple) fait monter la charge très
rapidement.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yves Rutschle
On Tue, Oct 26, 2010 at 11:30:35PM +0200, Goldy wrote:
Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré
l'entièreté du volume avec luks



Au fait, vous (Goldy, Kevin, JY) utilisez luks pour vous
protéger de quoi au juste?

(je vois l'intérêt sur un ordinateur portable, mais sur un
serveur je suis un peu sec).

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yves Rutschle
On Tue, Oct 26, 2010 at 11:22:12PM +0200, Jean-Yves F. Barbier wrote:
sur du vécu, un HD qui saute et des données irrécupérables après
son remplacement: en fait une impossibilité de récupérer les données malgré
que le LVM ne soit pas strippé.
Un arrêt normal du système et au démarrage pouf, une erreur et plus rien...



On est d'accord que "en principe" le RAID devrait
reconstruire allègrement une copie des LVM, et qu'il ne
s'agit donc pas d'un comportement que l 'on pourrait
attendre de raid+lvm?

une chose est toute fois à noter: depuis l'apparition du SATA et *surtout*
de ses connecteurs d'alim (quasiment aucune poss. de rupture de continuité
par vibrations, contrairement aux molex semi-circulaires), le risque a pas
mal reculé



Je n'ai jamais vu de connecteurs d'alim se sortir tout seul
(en général, j'ai plutôt eu du mal à les sortir à la main),
par contre j'ai vu des nappes IDE se sortir toutes seules...
la connectique SATA est clairement mieux.

sinon, pour la mathématique Murphyenne c'est simple: chaque couche a la
capacité de parasiter l'autre (DONC, elle le fera!) ce qui fait que tu
multiplies les possibilités d'échec par bien plus que le taux d'erreur
unitaire



D'accord avec ça, KISS, et je seconde ton conseil de prendre
un disque plus grand (et du RAID11, peut-être avec 3
disques).

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Sylvain L. Sauvage
Le mardi 26 octobre 2010 à 22:00:13, Kevin Hinault a écrit :
[…]
La on a la même chose partout :

fdisk de base :

# /sbin/fdisk.distrib -l /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
[…]



Oui euh, mais là, ce qui m’intéressait, c’à ©tait les tables
complètes. Suivant le logiciel et le mode utilisé (p.ex.
compatibilité avec DOS pour fdisk), le secteur de début de
partition diffère. En mode « cylindre », c’est toujo urs 1 mais
en mode « secteur », ça peut varier grandement (1, 32 et 204 8
sont les valeurs par défaut que j’ai observées). La comma nde
parted suivante permet de tout avoir :

parted /dev/sdb print unit s print unit chs print

(même si parted n’est pas franchement pratique, il a le mà ©rite
de gérer les GPT). Ou avec fdisk :

fdisk -lu /dev/sdb


Bon, finalement, la différence, c’est que, pour calculer la
taille en secteurs, gnu-fdisk utilise la bonne vieille méthode :

taille = nb_têtes × nb_cylindres × nb_secteurs_par_piste

fdisk et parted utilisent :

taille = taille_en_octets / taille_secteur

Et comme le nombre de têtes, de secteur par piste et de
cylindres sont faux (truqués pour compatibilité CHS), et que la
taille en octets est donnée directement par le disque, ce sont
fdisk et parted qui ont raison.

Bon, ça explique les fdisks, pas le mdadm. Dommage que t’aie s
pas gardé la table de partition.

[…]
Mais comment sait-on comment sont organisés les lv sur le vg
?



Ah ha ! La bonne question.
Rien ne dit que les extents libérés se retrouvent à la fin du
pv. En revanche, dans le man de pvresize, il est indiqué que
l’on ne peut pas réduire plus bas que les extents utilisé s
(qu’un jour, pvresize sera capable de les redescendre
automatiquement s’il y a de la place). Donc on doit peut-être
pouvoir y arriver par essai-erreur…


Le mardi 26 octobre 2010 à 23:02:59, Kevin Hinault a écrit :
[…]
Tes excellentes questions viennent de me sauver. […]



Tant mieux.

Et je gagne 2Mo environ.[…]



Ce qui fait beaucoup je trouve…

L'autre piste que j'aurais suivi ensuite aurais été de faire
un dd complet d'un disque à l'autre.



Euh, suis pas sûr que ça fonctionne, ça : ya pas deux-troi s
données spécifiques par disque ? (les UUID sont stockées ou
calculées ?)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Kevin Hinault
Le 27 octobre 2010 08:28, Yves Rutschle
a écrit :
On Tue, Oct 26, 2010 at 11:30:35PM +0200, Goldy wrote:
Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré
l'entièreté du volume avec luks



Au fait, vous (Goldy, Kevin, JY) utilisez luks pour vous
protéger de quoi au juste?




Bonne question. Je n'ai aucune réponse valable à te donner sinon
"parce que c'est possible".

--
Kévin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/AANLkTim9Qa7x7W0UY7S9W0+738Js+
1 2 3