Re: mdadm "not large enough to join array" et fdisk incohérent
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 toujours 1 mais
en mode « secteur », ça peut varier grandement (1, 32 et 2048
sont les valeurs par défaut que j’ai observées). La commande
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’aies
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-trois
données spécifiques par disque ? (les UUID sont stockées ou
calculées ?)
--
Sylvain Sauvage
Reply to: