lvextend s’exécute sans erreur, augmente bien la taille du volume logique selon la commande demandée, et pourtant df -h continue d’afficher exactement la même taille qu’avant pour le système de fichiers monté dessus. Ce n’est pas un échec silencieux de lvextend : le volume logique et le système de fichiers qu’il contient sont deux couches distinctes, et LVM ne redimensionne jamais la seconde automatiquement.

Deux couches, deux commandes différentes

LVM gère l’espace disque à un niveau bloc, indépendant du système de fichiers qui l’utilise : lvextend modifie la taille du volume logique lui-même (l’espace bloc disponible), mais le système de fichiers formaté à l’intérieur (ext4, xfs) continue de croire qu’il occupe l’ancienne taille tant qu’une commande spécifique à ce système de fichiers ne l’informe pas explicitement du changement.

# Étape 1 : agrandit le volume logique lui-même,
# l'espace bloc disponible augmente réellement
lvextend -L +10G /dev/vg-data/lv-data

# Étape 2 (obligatoire, distincte) : informe le
# système de fichiers ext4 de la nouvelle taille disponible
resize2fs /dev/vg-data/lv-data

# Étape 2 pour XFS : la commande et son
# comportement diffèrent d'ext4, xfs_growfs prend
# le point de montage, pas le device
xfs_growfs /data

Pourquoi df ne ment pas

df rapporte fidèlement la taille du système de fichiers tel qu’il se connaît lui-même, pas la taille du volume logique sous-jacent : après un lvextend sans l’étape de redimensionnement correspondante, df affiche exactement la vérité, un système de fichiers qui n’a simplement pas encore été informé de l’espace supplémentaire disponible.

# Confirme la taille réelle du volume logique
lvdisplay /dev/vg-data/lv-data | grep "LV Size"

# Confirme (ou infirme) que le système de fichiers
# a bien été informé de cette nouvelle taille
df -h /data

Combiner les deux étapes en une seule commande

lvextend accepte une option qui déclenche automatiquement le redimensionnement du système de fichiers correspondant, éliminant le risque d’oublier la seconde étape.

# -r déclenche automatiquement resize2fs ou xfs_growfs
# selon le type de système de fichiers détecté
lvextend -r -L +10G /dev/vg-data/lv-data

Le lien avec l’espace disque déjà couvert

Ce piège est le miroir exact de celui déjà documenté sur l’épuisement des inodes : dans les deux cas, un outil rapporte fidèlement un état réel du système de fichiers qui ne correspond pas à l’intuition première de l’opérateur, l’espace bloc disponible n’étant qu’une des dimensions à vérifier explicitement plutôt que supposée résolue par une seule commande.

À retenir

lvextend agrandit uniquement le volume logique, jamais le système de fichiers qu’il contient : df continue d’afficher l’ancienne taille tant qu’une commande dédiée (resize2fs pour ext4, xfs_growfs pour XFS) n’a pas explicitement informé le système de fichiers du changement. L’option -r de lvextend combine les deux étapes en une seule commande, éliminant le risque d’oublier la seconde. Ce comportement en deux couches distinctes rejoint le même principe déjà vu sur l’épuisement des inodes : l’espace disque a plusieurs dimensions indépendantes, chacune méritant une vérification explicite plutôt qu’une hypothèse.