Linux sans magie #46 — Étendre un volume LVM à chaud

Prévisualisation — contenu non publié.

Dans le #45, nous avons créé un Logical Volume (LV), préparé un filesystem et vérifié son montage. Le nouveau volume fonctionne. Quelques semaines plus tard, ses données occupent presque toute la capacité disponible.

Le réflexe peut être de rechercher un disque plus grand. Avec LVM, ce n'est pas toujours nécessaire : un Volume Group (VG) peut déjà disposer d'espace non attribué aux LV. Cet espace peut servir à agrandir un volume existant.

Mais étendre un LV ne signifie pas automatiquement agrandir le filesystem, et « à chaud » ne signifie pas « sans vérification ni risque ».

Comprendre la situation avant de modifier le stockage

Imaginons un système Linux dont l'application utilise un filesystem ext4 monté sur /srv/app. Ce filesystem repose sur le LV /dev/vgdata/lvapp.

Physical Volume(s)
       ↓
VG vgdata : 100 GiB
       ├── LV lvapp : 40 GiB → ext4 → /srv/app
       ├── autres LV
       └── espace libre : 20 GiB

Les chiffres sont illustratifs : ils ne décrivent pas tous les LV du groupe.

Le besoin est d'ajouter 10 GiB à lvapp, sans démonter le filesystem lorsque les composants le permettent.

Le même raisonnement vaut sur un PC, un serveur physique, une machine virtuelle ou une instance cloud. Ce sont les couches réellement présentes et les fonctionnalités du filesystem qui déterminent la procédure.

Deux capacités différentes : le LV et le filesystem

Reprenons la chaîne étudiée dans les articles précédents :

disque ou partition
       ↓
PV — Physical Volume
       ↓
VG — Volume Group
       ↓
LV — Logical Volume
       ↓
filesystem ext4 ou XFS
       ↓
point de montage

lvextend modifie l'allocation LVM : le LV obtient davantage d'extents depuis le VG.

Un filesystem ext4 ou XFS doit ensuite être agrandi pour exploiter cette nouvelle capacité. Tant que cette étape n'a pas été réalisée, df -h peut continuer d'afficher l'ancienne taille même si lvs indique un LV plus grand.

Il faut donc lire vgs, lvs et df ensemble.

Vérifier l'espace disponible dans le Volume Group

La première étape est entièrement en lecture seule :

sudo pvs -o pv_name,vg_name,pv_size,pv_free
sudo vgs -o vg_name,vg_size,vg_free
sudo lvs -o vg_name,lv_name,lv_size,lv_path,lv_attr

Pour notre scénario, nous cherchons un VG vgdata contenant bien lvapp et offrant au moins 10 GiB non attribués.

Un VG avec VFree = 0 ne peut pas fournir 10 GiB supplémentaires à un LV linéaire classique. Il faudrait d'abord augmenter la capacité disponible en amont, par exemple en intégrant un PV adapté au VG. Ce sujet doit faire l'objet d'une procédure distincte : il ne faut pas modifier une table de partitions ou initialiser un disque dans l'urgence.

Les chiffres doivent aussi être confrontés aux contraintes de l'application. Un filesystem presque plein peut contenir des fichiers temporaires, des logs ou des données orphelines : il est utile de comprendre la cause de la saturation avant de simplement lui ajouter de l'espace.

Identifier le filesystem et son montage

Avant de choisir un outil de croissance :

lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt /srv/app
df -hT /srv/app

findmnt confirme la source réellement montée sur /srv/app. La colonne FSTYPE de df -hT indique le type de filesystem.

Deux cas courants :

ext4 : resize2fs peut agrandir en ligne un filesystem monté lorsque le noyau et les fonctionnalités du filesystem le prennent en charge ;
XFS : xfs_growfs agrandit le filesystem monté, en utilisant notamment son point de montage.

Les deux outils ne sont pas interchangeables. Le fait qu'un LV soit géré par LVM ne supprime pas les contraintes de son filesystem.

Ce que signifie vraiment « extension à chaud »

Une extension est dite en ligne lorsqu'elle s'effectue pendant que le filesystem reste monté et disponible.

Cette possibilité existe pour les scénarios compatibles avec ext4 et XFS. Elle ne constitue pas une garantie universelle d'absence de latence, de panne ou d'impact applicatif.

Une sauvegarde restaurable, l'identification du volume, une surveillance active et un plan d'intervention restent nécessaires. Une erreur de device ou une saturation du stockage sous-jacent peut avoir des conséquences même lorsque la commande est autorisée sur un filesystem monté.

Ne transposez pas les commandes ci-dessous à un LV chiffré, thin-provisioned, répliqué ou partagé sans analyser les couches supplémentaires.

Mise en pratique : agrandir un LV existant

Cette procédure concerne un LV linéaire classique, situé dans un VG disposant déjà de capacité libre, et contenant un filesystem ext4 monté. Elle décrit une intervention à adapter à votre infrastructure : aucun nom de VG, de LV ou de montage ne doit être deviné.

Prérequis : Linux avec LVM2 et e2fsprogs, privilèges administrateur, filesystem ext4 compatible avec la croissance en ligne, sauvegarde vérifiée, capacité VG libre suffisante et changement autorisé.

Objectif vérifiable : ajouter 10 GiB au LV choisi, maintenir le montage, faire croître ext4 et contrôler que les fichiers existants restent accessibles.

Durée indicative : 15 à 25 minutes, hors sauvegarde et préparation du changement.

Étape 1 — Identifier formellement le volume

sudo lvs -o vg_name,lv_name,lv_size,lv_path,lv_attr
sudo vgs -o vg_name,vg_free
findmnt /srv/app
df -hT /srv/app

Dans la suite, /dev/vgdata/lvapp et /srv/app sont des valeurs d'exemple. Assurez-vous qu'elles correspondent réellement au volume et au montage autorisés avant toute écriture.

Étape 2 — Comprendre la syntaxe de `lvextend`

Pour ajouter une taille relative :

lvextend --size +10G /dev/vgdata/lvapp

Le signe + est essentiel. +10G signifie ajouter 10 GiB à la taille existante ; sans le +, l'argument exprime une taille totale cible.

La commande affecte de nouveaux extents au LV. Elle ne fait pas grandir automatiquement ext4 sans l'option adaptée ou une commande supplémentaire.

Étape 3 — Étendre le LV et le filesystem ensemble

Lorsque la cible est confirmée et que le filesystem est compatible :

sudo lvextend --size +10G --resizefs /dev/vgdata/lvapp

L'option --resizefs (ou -r) demande à LVM de redimensionner également le filesystem au moyen des outils appropriés.

Cette syntaxe est documentée par LVM2 et Red Hat pour l'extension de LV. Elle écrit réellement sur la configuration du stockage : ce n'est pas une commande de simple diagnostic.

Si la commande échoue ou retourne un avertissement, interrompez la procédure et examinez séparément l'état du LV et du filesystem avant toute nouvelle tentative.

Étape 4 — Vérifier la taille du LV

sudo lvs -o vg_name,lv_name,lv_size,lv_path
sudo vgs -o vg_name,vg_free

Le LV doit avoir grandi d'environ 10 GiB et le VG doit disposer d'une réserve réduite d'autant, sous réserve des unités et des extents LVM.

Ne considérez pas la procédure achevée à cette étape : LVM et filesystem peuvent présenter des tailles différentes.

Étape 5 — Vérifier le filesystem monté

findmnt /srv/app
df -hT /srv/app
lsblk -f

Le montage doit toujours être présent, avec le filesystem attendu, et df doit afficher une capacité supérieure à celle relevée avant le changement.

Une taille utilisable légèrement inférieure à celle du LV reste normale pour un filesystem qui réserve de l'espace à ses métadonnées.

Étape 6 — Contrôler les données applicatives

Vérifiez les services concernés, leurs journaux et la possibilité de lire les données existantes. Sur un environnement de test, un fichier témoin créé avant l'intervention permet une comparaison simple.

Ne créez pas arbitrairement un nouveau fichier dans un répertoire critique uniquement pour tester le changement. Adaptez la vérification à l'application et à son fonctionnement normal.

Alternative : séparer l'extension du LV de celle d'ext4

L'administrateur peut choisir deux commandes distinctes :

lvextend --size +10G /dev/vgdata/lvapp
resize2fs /dev/vgdata/lvapp

La première augmente le LV. La seconde augmente ext4, en ligne si les conditions sont réunies.

Cette séparation rend chaque couche plus visible lors d'un diagnostic. En revanche, elle ouvre une situation intermédiaire où le LV a grandi mais pas encore le filesystem. Il faut donc contrôler les résultats et le code retour de chaque outil.

Une utilisation réelle de ces commandes nécessite les mêmes vérifications et autorisations que la variante --resizefs.

Et si le filesystem est XFS ?

Sur XFS, le mécanisme diffère. Le filesystem doit être monté au moment de sa croissance.

Après extension du LV avec une procédure validée, l'outil spécifique est :

xfs_growfs /srv/app

Le chemin passé à xfs_growfs désigne ici le point de montage XFS, contrairement à l'exemple resize2fs utilisant le device ext4.

Pour un LV et un filesystem compatibles, lvextend --resizefs peut également déléguer à l'outil approprié. Consultez la documentation et les versions installées avant de généraliser.

XFS ne prend pas en charge la réduction en place. Il ne faut donc jamais confondre l'extension de cet article avec une opération inverse.

Que faire si l'extension ne produit pas la taille attendue ?

Si vgs annonce trop peu d'espace, ne lancez pas lvextend avec une taille non disponible. Identifiez d'abord le besoin réel et les possibilités d'extension du groupe.

Si lvs affiche la nouvelle taille mais que df n'a pas changé, vérifiez l'outil de redimensionnement du filesystem et les messages d'erreur. N'essayez pas mkfs.ext4 : formater ne signifie pas redimensionner, et cette opération détruirait les structures existantes.

Si findmnt révèle un autre filesystem que prévu, arrêtez-vous. La relation entre LV, device-mapper, filesystem et montage doit être établie avant toute action.

Si des erreurs d'E/S ou des symptômes applicatifs apparaissent, utilisez la procédure d'incident de l'environnement : une extension de capacité n'est pas une réparation de stockage défaillant.

Bonnes pratiques opérationnelles

Établissez une valeur de référence avant le changement : taille du LV, VFree du VG, capacité df, type de filesystem, point de montage et état des services.

Évitez d'attribuer systématiquement tout l'espace libre du VG à un seul LV. Une marge facilite l'exploitation et les extensions futures. Le bon dimensionnement dépend néanmoins des besoins réels, des sauvegardes et des seuils d'alerte.

Enfin, continuez à surveiller l'occupation après l'intervention. Une extension ne résout pas la cause d'une croissance anormale des données.

Sécurité

lvextend modifie les métadonnées et la taille du périphérique logique. La gestion des extents peut toucher plusieurs PV si le VG en contient plusieurs ; connaissez les dépendances de stockage sous-jacentes.

Une sauvegarde récupérable est indispensable lorsque les données sont importantes. Les snapshots et points de restauration éventuels doivent être compris dans le contexte de la plateforme, sans être présentés comme une garantie absolue.

Ne réalisez pas un redimensionnement sur un volume dont le type, le filesystem ou le montage restent incertains.

Limites et points de vigilance

Ce guide concerne l'extension d'un LV linéaire classique, avec capacité déjà disponible dans le VG, et des filesystems ext4 ou XFS compatibles.

Il n'aborde pas l'ajout de PV, les thin pools et leurs métadonnées, les volumes RAID LVM, les snapshots, le chiffrement LUKS ou les filesystems distribués. Ces configurations nécessitent d'autres contrôles, parfois d'autres commandes.

Le terme « à chaud » ne garantit pas l'absence d'interruption pour chaque couple système de fichiers/noyau ou chaque application. Le support réel dépend de la version et de la configuration.

Rollback

Agrandir un LV puis son filesystem ne se défait pas simplement en appliquant un signe négatif à lvextend.

La réduction obéit à des règles spécifiques : certains filesystems, notamment XFS, ne prennent pas en charge une réduction en place. Une tentative mal préparée peut entraîner une perte de données.

Avant l'extension, préparez donc une stratégie de retour arrière fondée sur une sauvegarde restaurable ou une récupération adaptée à la plateforme et au niveau de protection requis. Ne tentez pas de réduire le volume pour « annuler » une extension réussie.

Références officielles

Conclusion

Étendre un volume LVM à chaud consiste à faire parvenir la capacité supplémentaire du VG vers le LV, puis du LV vers le filesystem.

La méthode fiable est de vérifier l'espace disponible, identifier le montage et son filesystem, étendre les bons objets et confirmer la capacité ainsi que l'état des applications.

L'option lvextend --resizefs simplifie les opérations compatibles, sans supprimer les vérifications nécessaires. Dans le #47, nous étudierons le sujet inverse : réduire un volume LVM, avec les précautions et risques spécifiques à cette opération.