Pour information comparative : 
[root@localhost fedorix]# du -x -h -a /var/ | sort -r -h | head -30
6,0G	/var/
4,2G	/var/log
4,1G	/var/log/journal/59c14ad693354e8c9253e57589383a39
4,1G	/var/log/journal
856M	/var/spool
824M	/var/spool/abrt
631M	/var/lib
401M	/var/cache
370M	/var/lib/systemd/coredump
370M	/var/lib/systemd
366M	/var/spool/abrt/ccpp-2018-05-26-21:43:52.598510-11565/coredump
366M	/var/spool/abrt/ccpp-2018-05-26-21:43:52.598510-11565
255M	/var/spool/abrt/ccpp-2018-05-26-21:43:52.229988-11633
254M	/var/spool/abrt/ccpp-2018-05-26-21:43:52.229988-11633/coredump
210M	/var/cache/dnf
204M	/var/spool/abrt/ccpp-2018-05-26-21:09:25.876985-11383/coredump
204M	/var/spool/abrt/ccpp-2018-05-26-21:09:25.876985-11383
185M	/var/cache/PackageKit/27
185M	/var/cache/PackageKit
160M	/var/lib/rpm
134M	/var/lib/rpm/Packages
129M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@c7554dda7048426fa72674981416e7d9-00000000000005f6-00056aefeee247b2.journal
129M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@4ea9c32ab01447f18fb366f0df78d207-000000000000070b-000569ad4c4a6c19.journal
129M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@17e9509351dd4ef487d7ea50efa5e961-00000000001d7f5d-00056c6d129f6f94.journal
129M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@17e9509351dd4ef487d7ea50efa5e961-00000000001b6eb4-00056c40765a75f4.journal
129M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@17e9509351dd4ef487d7ea50efa5e961-000000000000071f-00056b491a814ca7.journal
129M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@000569ad4c6b8fa1-e07f9ed0f3cf1825.journal~
121M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@c7554dda7048426fa72674981416e7d9-0000000000155aaf-00056b3b6ab372aa.journal
121M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@c7554dda7048426fa72674981416e7d9-0000000000139f48-00056b3b2f0946a6.journal
121M	/var/log/journal/59c14ad693354e8c9253e57589383a39/user-1001@c7554dda7048426fa72674981416e7d9-000000000011e48e-00056b3af2878ba5.journal
chepioq wrote:Comment faites-vous pour avoir un /var aussi important ?
Chez moi il ne fait que 3,4 Gio 
# du -x -h -a /var/ | sort -r -h | head -30
3,4G	/var/
1,7G	/var/cache
1,4G	/var/lib
687M	/var/lib/mock/fedora-24-i386/root
687M	/var/lib/mock/fedora-24-i386
687M	/var/lib/mock
630M	/var/lib/mock/fedora-24-i386/root/usr
604M	/var/cache/yum/x86_64
604M	/var/cache/yum
536M	/var/cache/PackageKit
412M	/var/cache/yum/x86_64/27
401M	/var/cache/dnf
350M	/var/lib/rpm
305M	/var/lib/rpm/Packages
282M	/var/lib/mock/fedora-24-i386/root/usr/lib
256M	/var/log
192M	/var/cache/yum/x86_64/28
190M	/var/lib/mock/fedora-24-i386/root/usr/share
172M	/var/cache/yum/x86_64/28/fedora
170M	/var/cache/yum/x86_64/27/updates-testing
164M	/var/cache/yum/x86_64/27/fedora
161M	/var/tmp
154M	/var/lib/dnf
154M	/var/cache/dnf/updates-8bd9ef368505a5fd
151M	/var/cache/PackageKit/27
150M	/var/tmp/dnf-dominique-3257tfaf
148M	/var/cache/yum/x86_64/27/updates-testing/gen
143M	/var/cache/yum/x86_64/28/fedora/gen
142M	/var/cache/dnf/updates-8bd9ef368505a5fd/packages
141M	/var/cache/yum/x86_64/28/fedora/gen/primary_db.sqlite
Et chez moi, 2,5 Gio ...!
Houlà

J'ai que 440 M dans /var
Bah comme je l'ai dit tout dépend de ce que l'on fait.

Rien que d'utiliser mock pour l'empaquetage des paquets me prend 19Go pour F26/F27/F28/Rawhide
 du -x -h -a /var/ | sort -r -h | head -30            
53G     /var/
45G     /var/lib
26G     /var/lib/libvirt/images/FedRebond.qcow2
26G     /var/lib/libvirt/images
26G     /var/lib/libvirt
19G     /var/lib/mock
5,0G    /var/cache
4,5G    /var/cache/mock
3,9G    /var/lib/mock/fedora-rawhide-x86_64/root
3,9G    /var/lib/mock/fedora-rawhide-x86_64
3,7G    /var/lib/mock/fedora-28-x86_64
3,6G    /var/lib/mock/fedora-28-x86_64/root
3,3G    /var/lib/mock/fedora-rawhide-i386
3,2G    /var/lib/mock/fedora-rawhide-i386/root
3,1G    /var/lib/mock/fedora-28-i386/root
3,1G    /var/lib/mock/fedora-28-i386
2,9G    /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build
2,9G    /var/lib/mock/fedora-rawhide-x86_64/root/builddir
2,7G    /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/mesa-18.2.0-devel
2,7G    /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD
2,6G    /var/lib/mock/fedora-28-x86_64/root/builddir/build
2,6G    /var/lib/mock/fedora-28-x86_64/root/builddir
2,5G    /var/lib/mock/fedora-28-x86_64/root/builddir/build/BUILD/mesa-18.2.0-devel
2,5G    /var/lib/mock/fedora-28-x86_64/root/builddir/build/BUILD
2,2G    /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/mesa-18.2.0-devel/src
2,2G    /var/lib/mock/fedora-rawhide-i386/root/builddir/build
2,2G    /var/lib/mock/fedora-rawhide-i386/root/builddir
2,1G    /var/spool/abrt/ccpp-2018-02-19-08:30:44.114097-6469/coredump
2,1G    /var/spool/abrt/ccpp-2018-02-19-08:30:44.114097-6469
2,1G    /var/spool/abrt
Comme je ne fais pas de clean systématique, à fin d'éviter de régénérer les systèmes à chaque fois et donc de perdre du temps, il y a un certain besoin d'espace à prévoir. Et comme je l'ai dit, je n'ai pas eu envie de me prendre la tête pour le faire ailleurs.

Et pour les upgrades de versions de Fedora, il faut de l'espace de stockage le temps de la faire. Sachant qu'en plus cela vas dépendre de ce qui est installé...
Réponse à 
df -h
J'obtiens 
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
devtmpfs           3,9G       0  3,9G   0% /dev
tmpfs              3,9G     30M  3,8G   1% /dev/shm
tmpfs              3,9G    1,5M  3,9G   1% /run
tmpfs              3,9G       0  3,9G   0% /sys/fs/cgroup
/dev/sda2           38G    9,0G   27G  26% /
/dev/sda1           50M     18M   32M  36% /boot/efi
/dev/sda6          157G     48G  101G  33% /home
/dev/sda7           19G    6,0G   12G  34% /var
/dev/sda4          2,7G    9,4M  2,6G   1% /tmp
/dev/sda5          234G    189G   34G  85% /d
tmpfs              784M     16K  784M   1% /run/user/1000
Je fais des mises à jour très souvent. C'est cela qui encombre mon système de fichiers volumineux ? Comment faire le ménage si l'on "update" souvent, sans risque de perdre des fichiers nécessaires au bon fonctionnement de l'ensemble ?

D'un autre côté, mon système est devenu extrêmement lent, à la limite du gel pur et simple. Il ne réagit quasiment pas au clavier ou à la souris, et les temps d'attente deviennent prohibitifs pour travailler. Que faire dans ce cas ?
Merci.
Je viens de lancer la commande 
dnf clean all
pour essayer de gagner de l'espace disque.
Le résultat est limité : le contenu de /var a diminué de 1 % (34 % -> 33 %) soit - 190 Mo environ.

Les autres partitions ne semblent pas avoir changé (notamment /).
Tu peux réduire la taille des fichiers journaux dans /etc/systemd/journald.conf : voir man journald.conf
Je lis dans journald.conf : 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
(END)
Quels paramètres pourrais-je diminuer ou modifier parmi les fichiers journaux ?
Déjà tu peux activer la compression sur des logs la différence est très importante.

Tu as des outils graphique comme baobab si tu veux essayer de voir ce qui prend vraiment de la place.

que donne 
du -sh /var/*
?
As tu consulté le man journald.conf ? C'est bien expliqué.

Par exemple, mais il y a d'autres options, tu enlèves le # devant SystemMaxUse= et tu mets la valeur de ton choix en Mégas. Chez moi j'ai mis 400M.

La commande que madko vient de te donner est à lancer en root.
Salut,

▪ Tu peux oublier l'option "dnf clean all" cela efface les méta-datas que dnf re-téléchargera dès qu'il en aura besoin, compte tenu de la taille que cela représente (moins de 100Mo) ce n'est pas ça qui sature ta partition.

▪ Comme l'a souligné @Fifi tu peux affiner la configuration de journal pour qu'il ne grossisse pas démesurément, on en avait discuté ici (toutes les valeurs sont arbitraires à toi de choisir ce qui te parait le mieux pour ton système).

▪ Dans le message #5 on peut voir que le répertoire /var est à environ 3,4G et aujourd'hui dans le message #15 on observe qu'il est passé à 6G, presque le double cela me semble énorme en une seule journée.
Afin de comparer il serait intéressant d'avoir à nouveau le résultat de la commande suivante: 
# du -h -x -a | sort -r -h | head -30
Je donne mon analyse qui est très simpliste (et sûrement pas la mieux), selon tes résultats les répertoires les plus gros sont: 
/var/lib
/var/log
/var/spool
/var/systemd/coredump
Le premier me semble normal, en revanche si les trois autres grossissent beaucoup en peu de temps c'est qu'il y a un problème qui revient systématiquement puisque c'est là que sont répertoriés les bugs.

Vérifies que tes services fonctionnent correctement: 
# systemctl --failed
Vérifies tes erreurs dans les logs des trois derniers jours: 
# journalctl --since "-3d" -p err
Listes les bugs rencontrés, tu verras quelles sont les applications qui posent problème: 
$ abrt-cli list
Croises tous ces résultats en utilisant le net et Bugzilla et tu trouveras le coupable.
En espérant que cela t'aide à avancer un peu avec ce problème.


Bon courage.
A+