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

Le
Kevin Hinault
Bonjour à tous,

J'ai deux problème qui sont liés l'un à l'autre :

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
empilement comme celui-ci :

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

La semaine dernière, un de mes disques a commencer à déconner (erreur=
s
d'écritures diverses, erreurs visible avec smartmontools et l'outil
propriétaire du constructeur confirmait ça). 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]
   Number   Major   Minor   RaidDevice State
     0       0        0      =
  0      removed
     1     254        5       =
 1      active sync   /dev/dm-5
     2     254        4       =
 -      faulty spare   /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]
   Number   Major   Minor   RaidDevice State
     0       0        0      =
  0      removed
     1     254        5       =
 1      active sync   /dev/dm-5


J'ai renvoyé le disque au constructeur qui m'en a renvoyé un neuf de
même capacité aujourd'hui.
En le recevant, j'ai refait comme j'avais fait lors de la création du
raid, j'ai créé une partition vide (Empty, type=0) puis chiffré
celle-ci et voulu l'intégrer 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ème de taille mais si je vérifie
les tailles, je ne trouve pas ça,  au contraire je trouve une
différence entre gnu-fdisk et fdisk

gnu-fdisk me dit ça :

# 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 = cylinders of 16065 * 512 = 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 = cylinders of 16065 * 512 = 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 = cylinders of 16065 * 512 = 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 = cylinders of 16065 * 512 = 8225280 bytes


Mes deux questions sont :
Qui dois-je croire ?
Si c'est fidsk.distrib qui a raison, comment je peux dire à mon raid
d'utiliser un disque légèrement plus petit ?

--
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 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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Yves F. Barbier
Le #22722661
On Tue, 26 Oct 2010 20:32:20 +0200, Kevin Hinault


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/
Sylvain L. Sauvage
Le #22722651
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/
Goldy
Le #22723001
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/
Kevin Hinault
Le #22722991
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
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=
Yves Rutschle
Le #22723051
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/
Kevin Hinault
Le #22723041
Le 26 octobre 2010 20:56, Sylvain L. Sauvage

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+
Jean-Yves F. Barbier
Le #22723151
On Tue, 26 Oct 2010 21:53:14 +0200, Kevin Hinault
...
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
> 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/
Kevin Hinault
Le #22723131
Le 26 octobre 2010 22:12, Jean-Yves F. Barbier
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++
Jean-Yves F. Barbier
Le #22723141
On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle

ç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/
Kevin Hinault
Le #22723211
On Tue, 26 Oct 2010 21:42:02 +0200, 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 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 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/
Publicité
Poster une réponse
Anonyme