Hello,

Déjà merci pour ces réponses.
J'avais déjà fait le dfn clean all

J'ai suivi le conseil de winmandrake pour le cache de PackageKit (voir le lien ci-dessous)
winmandrake wrote:Énorme la place prise sur /
Effectivement, avant de redimensionner, il vaudrait mieux faire de la place correctement.
#dnf clean all
#rm -rf /var/cache/PackageKit
Un petit tour ici pour packagekit
Et là, miracle, le df -h donne ceci maintenant (passage de 97% à 57% d'utilisé pour /dev/mapper/fedora_pc6-root) : 
# df -h
Sys. de fichiers            Taille Utilisé Dispo Uti% Monté sur
devtmpfs                      7,8G       0  7,8G   0% /dev
tmpfs                         7,8G     48K  7,8G   1% /dev/shm
tmpfs                         7,8G    1,6M  7,8G   1% /run
tmpfs                         7,8G       0  7,8G   0% /sys/fs/cgroup
/dev/mapper/fedora_pc6-root    50G     27G   21G  57% /
tmpfs                         7,8G     28M  7,8G   1% /tmp
/dev/sda2                     477M    150M  299M  34% /boot
/dev/sda1                     200M    9,5M  191M   5% /boot/efi
/dev/mapper/fedora_pc6-home   401G    192G  189G  51% /home
tmpfs                         1,6G     32K  1,6G   1% /run/user/1000
Le lvresize me fait un peu peur. Il me semble qu'il faut s'assurer qu'on a pas de données dans la zone que l'on va supprimer lors d'une réduction...

J'ai effectivement pas mal d'applications dont une petite machine virtuelle pour faire tourner un Windows XP avec une ou deux applis Windows.

Au passage, voilà ce que donne, après purge du cache PackageKit, le du --exclude="/home" -x -h -a / | sort -r -h | head -30 (excellente commande que je ne connaissais pas) 
27G	/
18G	/usr
8,6G	/usr/share
6,4G	/var
4,2G	/var/log
4,2G	/usr/lib64
4,1G	/var/log/journal/b6db2224174e4e88a1d37622652c6951
4,1G	/var/log/journal
2,4G	/opt/lampp
2,4G	/opt
2,1G	/usr/lib
1,7G	/opt/lampp/htdocs/vv
1,7G	/opt/lampp/htdocs
1,6G	/usr/share/0ad
1,5G	/usr/share/doc
1,5G	/usr/share/0ad/mods/public/public.zip
1,5G	/usr/share/0ad/mods/public
1,5G	/usr/share/0ad/mods
1,2G	/opt/lampp/htdocs/[xxxxxxxxxxxxxxx]
1,1G	/var/cache
987M	/usr/share/locale
965M	/opt/lampp/htdocs/[xxxxxxxxxxxxxxx]
629M	/var/lib
620M	/usr/share/texlive
612M	/usr/bin
611M	/var/spool
610M	/usr/share/texlive/texmf-dist
535M	/var/cache/akmods/nvidia
535M	/var/cache/akmods
527M	/var/spool/abrt
Il y a aussi un utilitaire graphique dans "Administration / Analyseur d'utilisation des disques" qui fait de beaux camemberts et qui aurait pu m'aider à voir ce qui prenait anormalement trop de place...
Tu dois en outre avoir pas mal d'applications installées.

Les modifications de tailles sont faisable en toute sécurité mais il faut être méthodique.
Il me semble qu'il faut s'assurer qu'on a pas de données dans la zone que l'on va supprimer lors d'une réduction...
Mais non, resize2fs fait le travail proprement. Ca serait différent si tu diminuais la taille d'une partition ou d'un lv sans réduire le système de fichiers avant!
moudur wrote:Hello, 
...
4,1G	/var/log/journal/b6db2224174e4e88a1d37622652c6951
4,1G	/var/log/journal
...
Il y a aussi un utilitaire graphique dans "Administration / Analyseur d'utilisation des disques" qui fait de beaux camemberts et qui aurait pu m'aider à voir ce qui prenait anormalement trop de place...
à mon avis, il y 2Go à récupérer là. As-tu été voir ?
Gérard
fgland wrote:
moudur wrote:Hello, 
...
4,1G	/var/log/journal/b6db2224174e4e88a1d37622652c6951
4,1G	/var/log/journal
...
Il y a aussi un utilitaire graphique dans "Administration / Analyseur d'utilisation des disques" qui fait de beaux camemberts et qui aurait pu m'aider à voir ce qui prenait anormalement trop de place...
à mon avis, il y 2Go à récupérer là. As-tu été voir ?
Gérard
Oui, carrément. J'ai plusieurs gros fichiers de log de 2015 et 2016 !
Par contre, je ne sais pas comment limiter automatiquement la taille des logs à une taille beaucoup plus petite (par défaut c'est 4 Go, il paraît).
Il faut modifier la configuration du fichier /etc/logrotate.conf ?
Les options se règlent dans journald.conf regarde le man.
Nicosss wrote:
GuL wrote:L'option -r de lvresize veut dire resizefs. Elle te permet de redimensionner en même temps le système de fichier, ce qui fait gagner du temps et évite les erreurs.
ATTENTION au système de fichier, c'est un coup à tout perdre, les simples commandes citées ci-dessus ne suffisent pas !
nouvo09 wrote:
moudur wrote:Le lvresize me fait un peu peur. Il me semble qu'il faut s'assurer qu'on a pas de données dans la zone que l'on va supprimer lors d'une réduction...
Mais non, resize2fs fait le travail proprement. Ca serait différent si tu diminuais la taille d'une partition ou d'un lv sans réduire le système de fichiers avant!
J'ai déjà utilisé ces commandes sans soucis, mais je confirme qu'il ne faut surtout pas oublier l'option -r de lvresize, qui est l'équivalent d'utiliser resize2fs.
-r, --resizefs
Resize underlying filesystem together with the logical volume using fsadm(8).


Avec LVM, on peut considérer le système de fichier comme des poupées russes :
partition LVM > Physical Volume (PV) > Volume Group (VG) > Logical Volume (LV) > système de fichier ext4 ou swap
Pour réduire un LV, il faut commencer par réduire le système de fichier avec resize2fs puis réduire le LV d'exactement la même taille, sous peine d'écraser des données. Pour agrandir un LV, c'est le contraire : on commence par agrandir le LV puis on agrandit le système de fichier. Dans les deux cas, lvresize --resizefs fait le travail comme il faut, en déplaçant les données si besoin, et en redimensionnant le système de fichier au bon moment.

Pour compléter, un VG peut être créé à partir de plusieurs disques et contenir des LV à cheval sur les disques.
PV1 (100 Go) et PV2 (100 Go) > VG (200 Go) > LV1 (50 Go) et LV2 (150 Go) > systèmes de fichier /root et /home
On peut même aller encore plus loin : si on dispose d'un peu de place sur un SSD, on peut accélérer les disques à plateaux par le SSD au moyen d'un Thin Pool et d'un cache SSD. Voir à ce sujet le tutoriel que j'ai réalisé. Le Thin Pool permet d'accélérer simultanément plusieurs LV.
PV1 (SSD, 64Go) et PV2 (HDD, 500 Go) > VG (564 Go) > cache SSD (64 Go) > Thin Pool (500 Go) > LV1 (50 Go) et LV2 (450 Go) > systèmes de fichiers /root et /home
@GuL, tout à fait, mais il vaut mieux dissocier les actions afin de s'affranchir de tout souci, l'opération n'étant pas anodine et nécessitant d'être bien comprise. L'utilisation de e2fsck entre les manipulations du système de fichier est préférable aussi afin de s'assurer que tout est est OK, avant et après chaque opération.

A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil. Si la partie documentation t'intéresse alors tu pourrais peut-être contribuer https://doc.fedora-fr.org/wiki/Contribuer.
nouvo09 wrote:Les options se règlent dans journald.conf regarde le man.
Merci !

J'ai modifié la variable SystemMaxUse dans mon fichier /etc/systemd/journald.conf, elle était non définie (#SystemMaxUse=) et je l'ai passée à 500M, comme ci-dessous.
[Journal]
...
#RateLimitBurst=1000
SystemMaxUse=500M
#SystemKeepFree=
#SystemMaxFileSize=
...
Avec la commande "du --exclude="/home" -x -h -a / | sort -r -h | head -30", on voit ci-dessous que ça a bien été pris en compte (mon /var/log/journal ne fait plus que 553 M)
24G	/
18G	/usr
8,8G	/usr/share
4,3G	/usr/lib64
3,2G	/var
2,4G	/opt/lampp
2,4G	/opt
2,1G	/usr/lib
1,7G	/usr/share/0ad/mods/public/public.zip
1,7G	/usr/share/0ad/mods/public
1,7G	/usr/share/0ad/mods
1,7G	/usr/share/0ad
1,7G	/opt/lampp/htdocs/vv
1,7G	/opt/lampp/htdocs
1,5G	/usr/share/doc
1,4G	/var/cache
1,2G	/opt/lampp/htdocs/[...]
987M	/usr/share/locale
965M	/opt/lampp/htdocs/[...]
665M	/var/log
629M	/var/lib
620M	/usr/share/texlive
617M	/usr/bin
611M	/var/spool
610M	/usr/share/texlive/texmf-dist
553M	/var/log/journal/b6db2224174e4e88a1d37622652c6951
553M	/var/log/journal
542M	/var/cache/akmods
541M	/var/cache/akmods/nvidia
527M	/var/spool/abrt

Et le df -h montre que mon système est passé de 97% d'utilisation de mon disque à 51%
Sys. de fichiers            Taille Utilisé Dispo Uti% Monté sur
devtmpfs                      7,8G       0  7,8G   0% /dev
tmpfs                         7,8G       0  7,8G   0% /dev/shm
tmpfs                         7,8G    1,6M  7,8G   1% /run
tmpfs                         7,8G       0  7,8G   0% /sys/fs/cgroup
/dev/mapper/fedora_pc6-root    50G     24G   24G  51% /
tmpfs                         7,8G     32K  7,8G   1% /tmp
/dev/sda2                     477M    150M  298M  34% /boot
/dev/sda1                     200M    9,5M  191M   5% /boot/efi
/dev/mapper/fedora_pc6-home   401G    192G  189G  51% /home
tmpfs                         1,6G     44K  1,6G   1% /run/user/1000
Et donc, ça me va très bien, je vais en rester là, merci !

Merci GuL pour tes excellentes précisions sur le redimensionnement du système de fichier et son fonctionnement en poupées russes... Ca me servira peut-être plus tard si je finis quand même par manquer de place.
Nicosss wrote:A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil.
Oui, carrément ! 🙂
+ le nettoyage de PackageKit et la limitation de la taille des log, peut-être ?
Nicosss wrote:@GuL, tout à fait, mais il vaut mieux dissocier les actions afin de s'affranchir de tout souci, l'opération n'étant pas anodine et nécessitant d'être bien comprise. L'utilisation de e2fsck entre les manipulations du système de fichier est préférable aussi afin de s'assurer que tout est est OK, avant et après chaque opération.

A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil. Si la partie documentation t'intéresse alors tu pourrais peut-être contribuer https://doc.fedora-fr.org/wiki/Contribuer.
Tu as sans doute raison, mais il me semblait que e2fsck était fait automatiquement.

Je vais envoyer une suggestion à la liste de diffusion en charge de la documentation mais je n'aurai pas le temps de faire la mise en page (3 gamins + travail prenant + thèse en cours + passions).
6 jours plus tard
Merci à tous !!
GuL wrote:
Nicosss wrote:@GuL, tout à fait, mais il vaut mieux dissocier les actions afin de s'affranchir de tout souci, l'opération n'étant pas anodine et nécessitant d'être bien comprise. L'utilisation de e2fsck entre les manipulations du système de fichier est préférable aussi afin de s'assurer que tout est est OK, avant et après chaque opération.

A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil. Si la partie documentation t'intéresse alors tu pourrais peut-être contribuer https://doc.fedora-fr.org/wiki/Contribuer.
Tu as sans doute raison, mais il me semblait que e2fsck était fait automatiquement.

Je vais envoyer une suggestion à la liste de diffusion en charge de la documentation mais je n'aurai pas le temps de faire la mise en page (3 gamins + travail prenant + thèse en cours + passions).
Oui je sais ce que c'est 😉

Pour le e2fsck je ne crois qu'il soit fait automatiquement. En tout cas je ne prends pas le risque, même si je genre d'opérations est à la marge pour moi.

N'hésite pas à faire un mot à la ML.
taj wrote:Merci à tous !!
Merci à toi pour les encouragements :pint:
@Nicoss,
Mail envoyé à la mailing liste de la documentation Fedora-fr. Aucune réponse 😐
GuL wrote:@Nicoss,
Mail envoyé à la mailing liste de la documentation Fedora-fr. Aucune réponse 😐
Tu as bien envoyé à fedora-fr-doc (at) fedora-fr (dot) org ?
Je n'ai rien reçu et je ne vois rien dans la ML.
Si tu as 30" et veux en discuter, tu peux passer sur le salon Fedora sur Jabber https://candy.jabberfr.org/fedora@chat.jabberfr.org ou avec un client Jabber.
@Nicoss,
Inscription faite, message réenvoyé. A suivre. 🙂
GuL wrote:@Nicoss,
Inscription faite, message réenvoyé. A suivre. 🙂
C'est tout bon. Au plaisir !