Réallouer de l'espace sur du LVM sans se planter

Support Debian
#1

Hello,

J’ai installé vite fait une machine, avec la conf auto en lvm de tout l’espace de mon disque, bien que ce soit fonctionnel, la conf me plait pas trop :

[quote]Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/lab1-root
322M 123M 183M 41% /
tmpfs 982M 8,0K 982M 1% /lib/init/rw
udev 10M 640K 9,4M 7% /dev
tmpfs 982M 0 982M 0% /dev/shm
/dev/sda1 228M 9,4M 207M 5% /boot
/dev/mapper/lab1-home
63G 181M 60G 1% /home
/dev/mapper/lab1-tmp 368M 11M 339M 3% /tmp
/dev/mapper/lab1-usr 4,6G 562M 3,9G 13% /usr
/dev/mapper/lab1-var 2,8G 383M 2,3G 15% /var[/quote]

Je trouve pas ça très logique… Je souhaiterais réalouer plusieurs go de /home dans / qui en manque cruellement, ou à d’autres endroits, si vous avez d’autre propositions.

Donc de une, je souhaiterais avoir votre avis concernant une meilleurs optimisation de l’espace (sachant que je ne touche pas aux partitions elles même, pas moyen d’en supprimer ou rajouter).

Secundo, comment faire ça le plus proprement possible, à distance (je n’ai pas un accès facile à ces machines), sachant que je n’ai pas le droit à l’erreur…

Merci !

#2

Salut,

Voici mon “pense-bête”

[code]# pvcreate /dev/sda1

vgcreate /dev/sda1

lvcreate -L5G -n lv_name vg_name

vgdisplay -v vg_name

lvdisplay -v /dev/vg_name/lv_name

#mkfs.ext3 /dev/vg_name/lv_name

#umount /lvg_name/lv_name

lvextend -L+1G /vg_name/lv_name

e2fsck -f /dev/vg_name/lv_name

resize2fs /dev/vg_name/lv_name

mount /vg_name/lv_name

lvreduce -L -1G /dev/vg_name/lv_name

lvremove /dev/vg_name/lv_name[/code]

pvcreate /dev/sda1

vgcreate /dev/sda1

lvcreate -L5G -n lv_name vg_name

vgdisplay -v vg_name

lvdisplay -v /dev/vg_name/lv_name

#mkfs.ext3 /dev/vg_name/lv_name

#umount /lvg_name/lv_name

lvextend -L+1G /vg_name/lv_name

e2fsck -f /dev/vg_name/lv_name

resize2fs /dev/vg_name/lv_name

mount /vg_name/lv_name

lvreduce -L -1G /dev/vg_name/lv_name

lvremove /dev/vg_name/lv_name

1 - Tu sauvegardes puis tu réduis ton home.

2 - Tu attends que / ait besoin de grandir, mais étant donné que /usr est séparé tu risques d’attendre longtemps. :smiley:

#3

Bonsoir,

la partitionnement est pertinent, / n’a pas besoin d’être énorme tant que /var et /usr sont dans d’autres FS.
A moins que tu mettes pas mal de choses dans /root et que des librairies s’installent dans /lib.

Je trouve /var un peu grand, avec 1Go tu devrais être assez tranquille, si tu fais le ménage de temps en temps et que tu vides ton cache etc.

Si tu as de l’application lourde je monterais /tmp à 512Mo voir 1Go.

/usr semble bien taillé, si tu utilises ta machine uniquement en serveur tu peux le réduire c’est de la volumétrie perdue.

Pour résumer et être tranquille un minimum:
/ -> 512Mo
/var -> 1Go
/usr -> dépend de ton utilisation, la taille actuelle te laisse de la marge.
/tmp -> 512Mo
/home -> le reste, mais je garderais 5Go si jamais il y a besoin d’agrandir une autre partition.

Pour faire ça le plus proprement possible l’idéal serait de sauvegarder, recréer carrément les volumes logiques et d’y restaures les données afin d’avoir les extensions de ton LV de façon continue sur le disque ainsi que des données le moins possible fragmenté.

Sinon tu peux réduire les volumes logiques trop gros et augmenter les plus petits.
Réduction:
umount /monfs
e2fsck -fpC 0 /dev/monvg/monlv
resize2fs /dev/monvg/monlv TailleTotale-20M #réduire le fs plus petit que le Lv puis caller le fs sur le lv
lvreduce -L TailleTotale /dev/monvg/monlv
resize2fs -p /dev/monvg/monlv
mount /monfs

PS: la réduction est une opération dangereuse mal faite, sois sûr de ce que tu veux faire avant.

Augmentation:
lvextend -L TailleTotale /dev/monvg/monlv
resize2fs -p /dev/monvg/monlv

PS: l’augmentation fonctionne bien à chaud

#4

Hello, dans le cas présent :

Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/lab1-root 322M 123M 183M 41% / tmpfs 982M 8,0K 982M 1% /lib/init/rw udev 10M 640K 9,4M 7% /dev tmpfs 982M 0 982M 0% /dev/shm /dev/sda1 228M 9,4M 207M 5% /boot /dev/mapper/lab1-home 63G 265M 60G 1% /home /dev/mapper/lab1-tmp 368M 11M 339M 3% /tmp /dev/mapper/lab1-usr 4,6G 600M 3,8G 14% /usr /dev/mapper/lab1-var 2,8G 385M 2,3G 15% /var
Je voudrais obtenir un / de 1go (pour être vraiment tranquile) augmenter mon /tmp à 1go aussi et diminuer mon /home de 2go du coup.

Si je fais pour diminuer mon /home à 48 go au lieu de 60 :

umount /home e2fsck -fpC 0 /dev/mapper/lab1-home resize2fs /dev/mapper/lab1-home 47980 # pour 48 go - 20 mo lvreduce -L 48000 /dev/mapper/lab1-home resize2fs -p /dev/mapper/lab1-home mount /home

Pour la diminution et pour l’augmentation de /tmp par exemple :

lvextend -L 1024 /dev/mapper/lab1-tmp resize2fs -p /dev/mapper/lab1-tmp

Ce serait exactement ça ? :wink: Je peux pas me permettre d’erreurs là :stuck_out_tongue:

#5

[quote=“coldroom”]

umount /home e2fsck -fpC 0 /dev/mapper/lab1-home resize2fs /dev/mapper/lab1-home 47980 # pour 48 go - 20 mo lvreduce -L 48000 /dev/mapper/lab1-home resize2fs -p /dev/mapper/lab1-home mount /home

Pour la diminution et pour l’augmentation de /tmp par exemple :

lvextend -L 1024 /dev/mapper/lab1-tmp resize2fs -p /dev/mapper/lab1-tmp

Ce serait exactement ça ? :wink: Je peux pas me permettre d’erreurs là :p[/quote]

La tu es en blocs il faut spécifier que tu veux du méga:

umount /home
e2fsck -fpC 0 /dev/lab1/home #On ne tape jamais directement les liens du device mapper
#Attention 48000M n'est pas égal à 48Go !!
resize2fs /dev/lab1/home 47500M #Pour être sûr que tu n'ais pas 128 ou 256Mo en taille de d'extension
lvreduce -L 48000M /dev/lab1/home #Tu vas avoir une alerte comme quoi ton FS peut peter si t'as pas pris t'es précautions, faire Yes
resize2fs -p /dev/lab1/home
mount /home

Si ton uptime est trop haut il vaut démonter, passer le e2fsck etaggrandir.
Si /tmp n’est pas utilisé et que tu peux le démonter c’est toujours mieux, sinon:

lvextend -L 1024M /dev/lab1/tmp
resize2fs -p /dev/lab1/tmp

Avec ça tu peux pas te planter :wink:

#6

Je vais essayer ça, merci :slightly_smiling:

#7

sinon, j’ai encore une petite question : Je trouve que de réallouer du ext2 (ou 3) est quand même plus simple et moins craignos, pourquoi ?

J’avais choisi LVM parceque j’en avais entendu que du bien, nouveau système de fichier tout ça… mais au final je me rends compte que c’est bien plus délicat à gérer que du ext3, du coup, je pige pas bien quel est l’avantage du LVM par rapport au ext3, quelqu’un peut m’expliquer ?

#8

Salut,

LVM n’est pas un système de fichier mais un système de “partition” dans lequel on définit par la suite des systèmes de fichiers :slightly_smiling:

#9

Comme le dit ggoodluck47, LVM est un outils de partitionnement.

Je trouve 10x plus simple d’augmenter un FS sur un volume logique que de modifier une partition, après ce n’est que mon avis.
LVM à plus d’un avantage, je te conseil de te renseigner un peu dessus et tu en verras la puissance(striping, mirroring, snapshot…)

#10

Salut,

J’avoue que toucher à sa LVM en ligne de commande est un peu flippant quand on le n’a jamais testé…

Je l’ai fait il y a peu, et pour ne pas prendre de risques liés à mon manque d’expérience, j’ai lancé un livdCD, téléchargé system-config-lvm et j’ai fait ça en graphique… :blush:

Pas très “geek” comme méthode, mais j’ai obtenu ce que je souhaitais, redimensionner mes lvm sans prendre trop de risques (cad en visualisant les modifications…) - je suppose que l’interface graphique de lvm, comme c’est le cas pour tous les outils graphiques est un plus risqué d’utilisation que la ligne de commande…

#11

Salut Lol,

[quote] je suppose que l’interface graphique de lvm, comme c’est le cas pour tous les outils graphiques est un plus risqué d’utilisation que la ligne de commande…
[/quote]

Et c’est pour ne pas prendre de risques que tu l’as utilisé :wink:

#12

Lorsque je vois les commandes à passer je prend peur… Une seule erreur et c’est le drame. Les paquets sous Lenny sont censés être stables; Même les outils graphiques…

Dans ma Sid je n’imagine même pas utiliser LVM d’ailleurs…

Tu ne peux pas reprocher à quelqu’un d’utiliser un outil graphique (mis à sa disposition dans les dépôts) dans un système stable quand même… si ? :mrgreen:

#13

Re,

Relis toi : tu nous dis que les interfaces graphiques sont plus riqués et que c’est pour cela que tu as utilisé cet interface graphique pour ne pas prendre de risques :smiley: :smiley: :smiley:

#14

[quote=“ggoodluck47”]Re,

Relis toi : tu nous dis que les interfaces graphiques sont plus riqués et que c’est pour cela que tu as utilisé cet interface graphique pour ne pas prendre de risques :smiley: :smiley: :smiley:[/quote]

Je suis d’humeur badine, et j’ai la flemme de développer ce que tu as déjà compris… :smt006

Bon, j’y vais quand même, mais à mon corps défendant ! c’est plus facile de visualiser des camemberts et autres graphiques que des chiffres dans une console… :wink:

#15

C’est vrai qu’au premier abord ça donne pas trop envie de plonger les mains dedans.
Quand on comprend bien l’interaction entre Volume Groupe, Volume Logique et Systeme De Fichier on a peu de chances de se tromper.

J’aime pas trop les interfaces graphiques qui font tout et ne te permettent pas d’apprendre.
je ne sais pas si l’interface graphique de LVM te permet de visualiser les commande qu’elle passe afin de pouvoir les rejouer après.

PS: j’ai dit une bétise plus haut je la vois en me relisant, mais quand on passe l’option “-L” à lvextend et lvreduce l’unité par défaut est le Méga, mais je trouve tout de même plus “cohérent” de mettre une unité de valeur.

#16

Re,

Dans mon copié-collé j’ai essayé de les groupe dans l’ordre d’utilisation, parce que ce ne sont pas des commandes utilisées tous les jours et que j’ai une petite tête :slightly_smiling: