Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
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
Jean-Yves F. Barbier
On Tue, 26 Oct 2010 20:32:20 +0200, Kevin Hinault wrote:



J'ai un RAID 1 tout bête (en mirroring donc) depuis quelques mois qui
tournait pas mal mais il est un peu spécial : chacun des deux disques
est chiffré avec luks et le raid contient des LVM, c'est à dire un



pas terr comme organisation, mixer raid & lvm, c'est multiplier
les risques de pertes de données par au moins 10 - Sans compter
l'overhead rajouté par le fait que chaque membre de l'array a sa
propre encryption (quel intérêt, à part bouffer de la RAM et du CPU,
l'exercice de style peut-être?)

Si c'est fidsk.distrib qui a raison, comment je peux dire à mon raid
d'utiliser un disque légèrement plus petit ?



c'est impossible: on ne peut rajouter un disque|partoche dans un array que
s'il est de taille >= à l'existant (et c'est logique.)

--
good scout, n.:
Someone who knows the lay of the land and will take you to her.

--
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 à 20:32:20, Kevin Hinault a écrit :
Bonjour à tous,



’soir,

[…]
gnu-fdisk me dit ça :
[…]
Disk /dev/dm-4: 1000 GB, 1000194048000 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
[…]
# /sbin/fdisk.distrib -l /dev/dm-5
Disk /dev/dm-5: 1000.2 GB, 1000201712640 bytes



Soit 524288 octets = 512 kio de différence.

Que disent(-ils sur) les couches inférieures (notamment les
/dev/sd*) ?

Tu utilises directement /dev/sd. ou tu as fait une partition
/dev/sd.1 ?
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.)

Mes deux questions sont :
Qui dois-je croire ?



Sais pas. D’un côté, tout le monde dit que fdisk (le vrai ) est
moins fiable que cfdisk ou sfdisk (notamment sa propre page de
man),. De l’autre, j’ai toujours plus de facilité avec lui
qu’avec les autres…

Si c'est fidsk.distrib qui a raison, comment je peux dire à
mon raid d'utiliser un disque légèrement plus petit ?



Comme ça, on ne peut pas. Tu peux utiliser un disque plus grand
en perdant la différence. Donc tu pourrais à la rigueur essayer
de réduire successivement les couches du haut (ext3 + lv + vg +
pv) pour finalement réduire le md, En faisant bien attention de
récupérer l’espace à la fin.

Perso, j’essaierai d’abord de savoir pourquoi.

--
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
Goldy
Le 26/10/2010 20:47, Jean-Yves F. Barbier a écrit :

pas terr comme organisation, mixer raid & lvm, c'est multiplier
les risques de pertes de données par au moins 10 - Sans compter
l'overhead rajouté par le fait que chaque membre de l'array a sa
propre encryption (quel intérêt, à part bouffer de la RAM et du CPU,
l'exercice de style peut-être?)



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.

--
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/10/2010 20:47, Jean-Yves F. Barbier a écrit :

pas terr comme organisation, mixer raid & lvm, c'est  multiplier
les risques de pertes de données par au moins 10 - Sans compter
l'overhead rajouté par le fait que chaque membre de l'array a sa
propre encryption (quel intérêt, à part bouffer de la RAM et du CPU ,
l'exercice de style peut-être?)



Non parce que je pensais que c'était la seule solution. Tout simplement.

Quant à la RAM et au CPU, les performances sont très bonnes de ce côt é
là. Par contre, je ne suis pas d'accord avec toi, je ne vois pas en
quoi c'est une erreur de mixer lvm+raid. Les deux n'ont pas la même
utilité et peuvent être très bien utilisés en commun.

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 l e
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és ent

--
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/AANLkTi=Dh3rqupGA4=wvA_VRRwLDC-0J2yDnyXNSk=
Avatar
Yves Rutschle
On Tue, Oct 26, 2010 at 09:39:51PM +0200, Goldy wrote:
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).



Comment ça se fait, LVM et raid marchent bien séparément
mais ne couchent pas bien ensemble sans que ça ai jamais été
débuggé?

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
Kevin Hinault
Le 26 octobre 2010 20:56, Sylvain L. Sauvage
a écrit :

Soit 524288 octets = 512 kio de différence.

Que disent(-ils sur) les couches inférieures (notamment les
/dev/sd*) ?



Bonne idée, je n'ai pas pensé à vérifer :

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

# /sbin/fdisk.distrib -l /dev/sdc
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes

gnu-fdisk :

# fdisk -l /dev/sdb
GNU Fdisk 1.2.4
Disk /dev/sdb: 1000 GB, 1000202273280 bytes

# fdisk -l /dev/sdc
GNU Fdisk 1.2.4
Disk /dev/sdc: 1000 GB, 1000202273280 bytes

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.)



Non je n'ai pas pensé a garder la table de partition. (Mais quel
couillon par moment) >_<

Mes deux questions sont :
Qui dois-je croire ?



Sais pas. D’un côté, tout le monde dit que fdisk (le vrai) est
moins fiable que cfdisk ou sfdisk (notamment sa propre page de
man),. De l’autre, j’ai toujours plus de facilité avec lui
qu’avec les autres…

Si c'est fidsk.distrib qui a raison, comment je peux dire à
mon raid d'utiliser un disque légèrement plus petit ?



Comme ça, on ne peut pas. Tu peux utiliser un disque plus grand
en perdant la différence. Donc tu pourrais à la rigueur essayer
de réduire successivement les couches du haut (ext3 + lv + vg +
pv) pour finalement réduire le md, En faisant bien attention de
récupérer l’espace à la fin.



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

--
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/AANLkTim2u_nPSthA-ozSeUz9OkyY+
Avatar
Jean-Yves F. Barbier
On Tue, 26 Oct 2010 21:53:14 +0200, Kevin Hinault wrote:

...
Quant à la RAM et au CPU, les performances sont très bonnes de ce côté
là.



Wai, c'est aussi le leit-motiv de ceux qui font les javascripts qui
bloquent 100% de mon vieux CPU (mais 1% sur un 8 cores avec 100MB de
RAM...)

Plus sérieusement, c'est aussi multiplier les risques (perte de clà ©(s),
glitch électrique, etc.)

Par contre, je ne suis pas d'accord avec toi, je ne vois pas en
quoi c'est une erreur de mixer lvm+raid. Les deux n'ont pas la même
utilité et peuvent être très bien utilisés en commun.



Comme l'a dit Lao Zi, l'expérience est une lanterne qui n'éclaire que le
chemin de celui qui la porte.
Une (ou ptêt deux) fois que tu auras perdu toutes tes données à   cause du
couple infernal, tu sauras pourquoi (V. aussi le post de Goldy; perso, j'ai
aussi eu le même cas, et ça énerve passablement qd ça a rrive.)

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



Une meilleure question à se poser: au prix où sont les HDz actuel s et vu
les capacités, quel est l'intérêt d'utiliser LVM alors qu'on peut
"agrandir" autant qu'on veut sans cette couche, en montant simplement un
nouvel array sur un point situé dans l'original.

--
A figure with curves always offers a lot of interesting angles.

--
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:12, Jean-Yves F. Barbier a écrit :
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



Une meilleure question à se poser: au prix où sont les HDz actuels et vu
les capacités, quel est l'intérêt d'utiliser LVM alors qu'on peut
"agrandir" autant qu'on veut sans cette couche, en montant simplement un
nouvel array sur un point situé dans l'original.



Oh j'ai bien une réponse qui tient en trois :
1 / si les disques semblent illimités, les ports ne le sont pas sur
une même machine.
2 / il faut connaître cette technique dont je n'ai pas connaissance.
Tu parlais d'expérience qui n'éclaire que le porteur. Je suis d'accord
avec toi si le porteur garde la lumière pour lui. On est dans le cas
où le manque de doc est flagrant et où l'expérience est limité. Alo rs
oui j'explore, oui je me plante, oui je suis humble et parfois demande
mon chemin quand ma lanterne ne suffit pas. Le fait d'en parler
suffira peut être à empêcher d'autres de faire la même bêtise.
3 / L'intérêt est la facilité de modification des lv à chaud.

--
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/AANLkTikfGUAcLgG8m0hs++
Avatar
Jean-Yves F. Barbier
On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle
wrote:

ça n'est pas une question de bug, il suffit qu'un seul bit saute au ma uvais
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 pas une
évolution linéaire des PBs, mais plutôt exponentielle.

On Tue, Oct 26, 2010 at 09:39:51PM +0200, Goldy wrote:
> 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).

Comment ça se fait, LVM et raid marchent bien séparément
mais ne couchent pas bien ensemble sans que ça ai jamais étà ©
débuggé?

Y.





--
Obviously the only rational solution to your problem is suicide.

--
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
On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle
wrote:
On Tue, Oct 26, 2010 at 09:39:51PM +0200, Goldy wrote:
> 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 e n le
> réintégrant à l'array (raid5 + lvm + chiffrement).

Comment ça se fait, LVM et raid marchent bien séparément
mais ne couchent pas bien ensemble sans que ça ai jamais été
débuggé?






Le 26 octobre 2010 22:19, Jean-Yves F. Barbier a écrit :
ça n'est pas une question de bug, il suffit qu'un seul bit saute au mau vais
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 pas une
évolution linéaire des PBs, mais plutôt exponentielle.



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 erre urs
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 donn ées
puisque la structure des deux luks aurait été abimée.

--
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/
1 2 3