Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 21:53:14 +0200, Kevin Hinault <hinault@gmail.com> 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 arrive.)
> Le 26 octobre 2010 21:39, Goldy <goldy@goldenfish.info> 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 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.
--
A figure with curves always offers a lot of interesting angles.
Reply to: