[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Tue, 26 Oct 2010 22:30:10 +0200, JC <jc2010@aygalenq.net> 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 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 quoi
> se base une telle affirmation ?

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

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é (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'erreur
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


Reply to: