Salut,

Merci pour ces retours ainsi que toutes ces explications ! Ça me rassure énormément :)

@Johann

> Tu as une solution pour résoudre le soucis du pmspare qui n'a plus la bonne taille :
> - Éteint toute tes VM utilisant le thinpool
> - Démonte tout ce qui tape dedans
> - Effectue ensuite un "lvconvert --repair  v2cold/data2cold"
>
> [...]

Elle est top cette procédure et les explications qui vont avec aussi :) Merci !
Je vais faire progressivement mes 3 thinpool en commencant par le moins sensible : data2cold

> > augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold
> Je pense que c'était superflu, d'après ton lvs -a, tu n'utilise que ~52% de data sur les 11.3T que tu as maintenant.
> Sauf si ce message était dû au fait que tu as réservé plus que les 11T sur l'ensemble des LV thin de tes VM?
> Si c'est le cas, à toi de voir, si tu ne penses jamais utiliser tous les disques au maximum... Après si tu préfères la sécurité et que ta la capacité disponible!

Effectivement, n'étant pas trop sûr de ce que je faisais, j'ai laissé les anciens LV Thin au cas où...  Bien que je n'utilise que ~52%, j'ai probablement dépassé les 11T de provisionné.
Vais pouvoir attaquer le ménage bientôt :)

> >  J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64
> Effectivement c'est une bonne technique, j'avais dû la voir à une époque mais elle m'était sortie de la tête.
> Même si avec ces calculs je trouve le double de ceux que j'aurais en vrai si je suis mon utilisation actuelle.
> Je ne sais pas si je suis fatigué et raté quelque chose, possible... Soit un détail m'échappe dans le calcul. Après ça vaut mieux trop que pas assez.
> Mais n'oublie pas que cela serait les valeurs maximum théorique utilisées et pas l'utilisation actuelle. Mais tu tombes comme moi sur une valeur supérieure à la réalité.

Arf... j'aurai du rajouter la visu pour data0hot et data1middle dans le "lvs -a" et ce dernier est d'ailleurs réalisé a posteriori de la "réparation" (j'aurai du le préciser)
  data0hot (taille 930G, chunk 512K) :
    - calculé : 122 Mo
    - constaté : 120 Mo avec pour usage Data%=64.23 et Meta%=88.02%
  data1middle (taille 1,64T, chunk 1M) :
    - calculé : 111 Mo
    - constaté : 108 Mo avec pour usage Data%=3,02% et Meta%=11,93%
Je me suis peut être trompé dans mes calculs. Mais comme tu le précises bien, autant voir large surtout qu'on n'est pas sur les mêmes ordres de grandeur entre Data et Meta

> > J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...)
> J'ai testé, cela marche pas trop mal, si tu dépasse le thin_pool_autoextend_threshold% d'utilisation des meta, cela augmente de thin_pool_autoextend_percent% celui-ci.
> Mais je me suis retrouvé avec un cas étrange où cela augmente le tmeta mais pas le pmspare.
> Je ne sais pas si c'est volontaire, un bug, un souci de configuration de mon côté.

Ah ok, du coup j'élimine cette option. Merci.

> Dans tous les cas avant manipulation, check l'état de tes backups. On ne sait jamais.

Avec l'absence de backup hors-site, j'ai actuellement 3 duplication de backups sur site (ressource2cold... pas top ^^, un sur SoC et un autre sur mon LAB) et je refuse tout crash de météorite, inondation ou incendie sur ces prochains jours (et ceux d'après aussi :P )

@Stéphane

Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il s'agissait)
C'est intéressant comme approche votre gestionnaire de cluster (et ca m'éclaire un peu plus sur le fonctionnement et rôle des metas)