Hello tout le monde,  
 
J'aurais avoir quelques explications. A mon boulot, je souhaiterai augmenter certains FS. Nous sommes sous Linux (Redhat).  
 
J'ai donc augmenté la taille du volume logique relatif au FS. J'ai lancé la commande  

 
Lorsque j'affiche la taille du volume logique  

 
Cela confirme que la nouvelle taille est prise en compte.  
Par contre lorsque je fais un  

 
 
je m'appercois que la taille reste identique. J'avais fait la même opération pour le FS /tmp et en augmentant le le volume logique, cela avait automatiquement augmenter la taille du FS.  
 
Je viens de voir dans une doc, qu'il faudrait que j'execute également cette taille  

source : https://www.system-linux.eu/index.p [...] ion-FS-lvm
 
J'aurais aimé savoir pourquoi dans certains cas, il faut faire un resieze et dans d'autres cas ce n'est pas necessaire et dans d'autres oui.  
 
J'imagine que la commande resize2fs permet au FS d'occuper l'entièreté du lecteur logique. Le volume logique est une coquille vide comme et lorsque l'on l'augmente, il y a de l'espace inoccupé. Il faaut donc augmenter dans un second temps, le FS réutilisé cet espace vide.  
 
Corrigez moi si je me trompe. Je ne pose pas réellement, j'aimerai juste avoir une confirmation pour savoir si je suis complètement à coté de la plaque ou pas
 

C'est le fonctionnement normal, le FS n'a pas connaissance de l'espace libre qui lui a été mis à disposition jusqu'à ce qu'on lui passe la commande idoine. Les cas où ça se fait automatiquement concernent des systèmes incluant aussi la gestion des volumes (Brtfs ou ZFS, par exemple). Il faudrait voir comment sont partitionnées les machines où le /tmp s'est automatiquement étendu.

Donc ton VG "rootvg" avait encore de l'espace libre et tu as étendu le LV "/dev/rootvg/r_tmp" avec 3G. Il te reste à étendre le file system de cet LV et pour cela tu dois en connaître le type. La commande "df -T" te permettra de le savoir.
Admettons que df -T te donne le type ext4 pour /dev/rootvg/r_tmp il te faudra exécuter "resize4fs /dev/rootvg/r_tmp"
 

Pour la prochaine fois, tu as aussi l'option -r de lvextend pour redimmentionner automatiquement le FS.
 

Merci à vous tous pour vos réponses
 
Okay, c'est un comportement  normal de devoir agrandir explicitement le FS après avoir augmenté son volume logique mais je viens donc à me poser la question, dans quelle situation, on ne lancerait pas la commande de redimensionnement du FS après avoir agrandit le Volume Goupe ?  
 
J'ai du mal à voir un intéret à ne pas exécuter la commande resize (pour du ext3/ext4)  donc j'ai du mal à voir un intêret que ce ne soit pas fait automatiquement.  
 
Okay demain(ou plutot tout à l'heure), je vais regarder  le type de FS utilisé pour mon /tmp qui s'est agrandit automatiquement  
 
Okay merci pour l'astuce Humar

Les volumes ne font que présenter la volumétrie au système, mais le FS peut être de n'importe quel type (ext4, XFS, ReiserFS, etc.), le volume peut même être utilisé en mode raw dans certains cas. Donc le design de base de lvextend prévoyait de laisser à l'admin le soin d'effectuer l'extension du FS lui-même en invoquant la bonne commande. Je ne sais pas quand est apparue l'option -r, mais on notera qu'elle invoque la commande fsadm, laquelle ne gère que certains FS :
 

Lvm n'est pas censé savoir s'il y a un file system dans le volume, et si le système peut l'étendre.
Ce serait un problème si le résultat de la commande était différent en fonction du système de fichier.
 
Pour être plus clair, si tu lance la même commande sur 2 volumes identiques (sans parler du contenu - aka systèmes de fichiers), et que tu obtient 2 résultats différents (un volume dans lequel le système de fichier à été étendu, l'autre non), c'est un problème de conception de ton programme.
 
Du coup comme tu ne peux pas garantir le resize de ton système de fichier, par défaut tu ne le fais pas, et une option de permet de l'integrer pour les systèmes de fichiers supportés.