df : plus d'espace disque mais... [Réglé]
... du n'est pas d'accord
Système et matériels / Installation et configuration
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
En voulant imprimer, je constate que ça marche plus.
Je vais dans CUPS admin où je trouve le message "Can't copy stdin to temporary file cups".
Sur internet, ils disent que c'est parcequ'il n'y a plus de place dans /tmp.
Vérification :
Code BASH :
$ df Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur devtmpfs 1,9G 0 1,9G 0% /dev tmpfs 1,9G 0 1,9G 0% /dev/shm tmpfs 1,9G 920K 1,9G 1% /run /dev/sda6 28G 26G 0 100% / tmpfs 1,9G 0 1,9G 0% /sys/fs/cgroup tmpfs 1,9G 48K 1,9G 1% /tmp /dev/sda8 133G 65G 62G 52% /home tmpfs 386M 12K 386M 1% /run/user/1000 tmpfs 386M 0 386M 0% /run/user/0
C'est vrai...sauf que :
# du -Pxs /
6,4G /
Donc j'ai environ 20 G sur /dev/sda6 qui sont dans la nature !
Je regarde les messages d'init et je trouve bien :
Oct 17 20:06:53 maman partmon[900]: Vérification si les partitions disposent d'assez d'espace libre :
Oct 17 20:06:53 maman partmon[900]: Warning, free space for </> is only <0> (which is inferior to <20000>
Oct 17 20:06:53 maman partmon[900]: [ÉCHEC ]
sauf que si je copie un fichier de 700 Mo dans /tmp je n'ai pas d'erreur !!
Y-aurait-il une bonne âme pour m'expliquer ces subtilités...
... et faire remarcher mon imprimante
Édité par zwykx Le 18/10/2017 à 14h03
Yuusha Membre non connecté
-
- Voir le profil du membre Yuusha
- Inscrit le : 04/07/2017
- Groupes :
-
Modérateur
-
Administrateur
-
Forgeron
Pour /tmp, tu n'as bien que 1% d'utilisé donc, il me parait normal que tu puisse copier directement un fichier de 700 Mo dedans. Après quand la partition / est pleine, le PC ne peux plus faire grand chose. N'as-tu pas un énorme fichier journal qui s'écrirait ? Je dis ça car cela m'est déjà arrivé avec un logiciel maison
.Chez moi du -Phxs et df -h donnent le même résultat, c'est étrange. Et quand tu vas dans drakrpm, quel espace disque restant te donne-t-il ? Si je ne me trompe pas, il est normalement égal à l'espace disque restant dans la partition /.
magnux77 Membre non connecté
-
- Voir le profil du membre magnux77
- Inscrit le : 21/09/2009
- Groupes :
-
Membre d'Honneur
Déjà le fait que 26G utilisés sur 28G = 100%...
Je pense qu'il faut que tu fouilles à coup de
Code BASH :
et de du -sh /* du -sh /var/*
Code BASH :
et que tu descendes au fur et à mesure vers où se concentre la surconsommation.
ls -al
m@rco123 Membre non connecté
-
- Voir le profil du membre m@rco123
- Inscrit le : 15/05/2009
- Groupes :
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Yuusha :
Pour /tmp, tu n'as bien que 1% d'utilisé donc, il me parait normal que tu puisse copier directement un fichier de 700 Mo dedans.
J'avoue que je ne suis pas très familier avec ces systèmes de fichier tmpfs, mais logiquement, je ne vois pas où il peut trouver de la place ailleurs que sur sda6.
Le problème initial c'est que CUPS ne peut pas créer de fichier temporaire donc écrire sur /tmp. Or apparemment, c'est possible.
Mais bon, j'ai répété l'opération en écrivant sur /root et ça a marché sauf que sda6 est passé à 27G utilisé.
Puis j'ai recommencé et là j'ai eu un message d'erreur :
cp: erreur d'écriture de '/root/fic2.avi': Aucun espace disponible sur le périphérique
et sda6 est passé à 28G :
/dev/sda6 28G 28G 0 100% /
Yuusha :
N'as-tu pas un énorme fichier journal qui s'écrirait ?
Peut-être mais "du -Pxs /" aurait du me dire que / était plein.
Yuusha :
Et quand tu vas dans drakrpm, quel espace disque restant te donne-t-il ?
Chez moi, drakrpm m'ouvre le MCC sur l'installation de paquetage mais ne donne pas de renseignements sur l'espace disque !
magnux77 :
Je pense qu'il faut que tu fouilles à coup de
du -sh /*
du -sh /var/*
du -sh /*
du -sh /var/*
-> du n'est toujours pas plus bavard !
Caché :
Code BASH :
# du -sh /* 0 /bin 60M /boot 44K /dead.letter 0 /dev 34M /etc 34M /etc.i586 65G /home 4,0K /initrd 0 /kdeinit5__0 0 /klauncherJ10412.1.slave-socket 0 /klauncherJ22921.1.slave-socket 0 /klauncherTJ8722.1.slave-socket 0 /lib 0 /lib64 16K /lost+found 4,0K /media 8,0K /mnt 16M /opt du: impossible d'accéder à '/proc/15222/task/15222/fd/4': Aucun fichier ou dossier de ce type du: impossible d'accéder à '/proc/15222/task/15222/fdinfo/4': Aucun fichier ou dossier de ce type du: impossible d'accéder à '/proc/15222/fd/4': Aucun fichier ou dossier de ce type du: impossible d'accéder à '/proc/15222/fdinfo/4': Aucun fichier ou dossier de ce type 0 /proc 37M /root 28M /root.old 920K /run 0 /sbin 4,0K /srv 0 /sys 12K /tmp 5,1G /usr 1,2G /var
Caché :
Code BASH :
# du -sh /var/* 4,0K /var/avahi 123M /var/cache 48K /var/catman 864K /var/db 4,0K /var/empty 4,0K /var/games 437M /var/lib 4,0K /var/local 0 /var/lock 583M /var/log 0 /var/mail 4,0K /var/nis 4,0K /var/opt 4,0K /var/preserve 0 /var/run 22M /var/spool 1,2M /var/tmp 4,0K /var/yp
rien d'anormal non plus dans /var/log/journal/XXXXXXXX/
Yuusha Membre non connecté
-
- Voir le profil du membre Yuusha
- Inscrit le : 04/07/2017
- Groupes :
-
Modérateur
-
Administrateur
-
Forgeron
zwykx :
Chez moi, drakrpm m'ouvre le MCC sur l'installation de paquetage mais ne donne pas de renseignements sur l'espace disque !
Yuusha :
Et quand tu vas dans drakrpm, quel espace disque restant te donne-t-il ?
Chez moi, drakrpm m'ouvre le MCC sur l'installation de paquetage mais ne donne pas de renseignements sur l'espace disque !
Et tout en bas au centre, tu as : Sélectionnés xxO / Place libre sur le disque : xxO. Mais bon ce n'est pas important, ça doit utiliser df ou une autre commande dans ce genre.
Par contre cette réponse pourrait t'intéresser. En root, il faudrait que tu regardes dans le système de fichier /proc s'il n'y a pas quelque chose d'énorme. du ne le verrait pas forcément mais df oui.
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Yuusha :
Par contre cette réponse pourrait t'intéresser.
J'ai essayé "lsof | grep '(deleted)'" et j'ai tué quelques process mais ça n'a rien changé.
J'ai regardé dans /proc. Il y a bien kcore mais il existe sur toutes les autres machines sans poser de problème et il est pas comptabilisé par df :
Code BASH :
# ll -h /proc ... -rw------- 1 root root 128T oct. 18 16:25 kcore ... # df /proc Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur proc 0 0 0 - /proc
En tout cas, df ou partmon utilisent un appel système du noyau (statfs pour partmon et stat pour df) pour trouver l'espace libre sur la partition.
statfs par exemple lit une structure (struct kstatfs) qui lui indique l'espace libre.
Par contre, je ne sais pas comment kstatfs est rempli.
Édité par zwykx Le 18/10/2017 à 17h36
magnux77 Membre non connecté
-
- Voir le profil du membre magnux77
- Inscrit le : 21/09/2009
- Groupes :
-
Membre d'Honneur
zwykx :
-> du n'est toujours pas plus bavard !
Personnellement, si je voyais que / de 28G est plein et que le total des sous-dossiers qui dépassent le Go /usr et /var ne fait 3.6 Go j'aurais cherché avec des ls -al au niveau /
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Encore faut-il pouvoir l'installer.
Peut-être désinstaller au préalable une application, ou faire un peu de purge avec des fichiers de log dans /var/log
Mais, c'est clair quelque chose ne va pas.
Certains fichiers/répertoires pourraient être masqués par des points de montage, genre /home, /tmp
Comme il est impossible de les démonter avec le système en fonctionnement, je recommande d'explorer le disque depuis une session Live, depuis un DVD ou une clé USB.
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
magnux77 :
Personnellement, si je voyais que / de 28G est plein et que le total des sous-dossiers qui dépassent le Go /usr et /var ne fait 3.6 Go j'aurais cherché avec des ls -al au niveau /
L’interprétation de ls est pas évidente.
Si par exemple je tape ce qui suit :
Code BASH :
$ mkdir ~/z $ echo "1">~/z/.a $ echo "12">~/z/.b $ ls -la ~/z total 16 drwxr-xr-x 2 root root 4096 oct. 19 13:55 ./ drwx------ 42 root root 4096 oct. 19 14:07 ../ -rw-r--r-- 1 root root 2 oct. 19 13:55 .a -rw-r--r-- 1 root root 3 oct. 19 13:55 .b $ ls -sa ~/z total 16 4 ./ 4 ../ 4 .a 4 .b $ du -Pxs ~/z 12K /root/z
"ls -la ~/z" affiche un total de 16Kio alors que 4096 + 4096 + 2 + 3 = 8197 ≃ 8Kio donc différent de 16Kio
"ls -sa ~/z" est plus cohérent mais charge .a et .b à 4Kio
et "du -Pxs ~/z" lui trouve 12Kio !
Qui croire ?
J'ai quand-même fait une recherche avec ls :
Code BASH :
et je trouve un total de 7 009 368 Kio ce qui correspond à 6.7 Gio donc on est pas loin du compte annoncé par du (6,4Gio).$ echo 'ls -sa "$1" | head -n 1' >c; find / -xdev -type d -exec sh c {} \; | cut -d ' ' -f 2 | while read n; do t=$((t + n)); echo $t; done $ ..... $ ..... $ 7009368
Papoteur :
Certains fichiers/répertoires pourraient être masqués par des points de montage, genre /home, /tmp
Oui, je vais regarder ça.
Édité par zwykx Le 19/10/2017 à 15h25
magnux77 Membre non connecté
-
- Voir le profil du membre magnux77
- Inscrit le : 21/09/2009
- Groupes :
-
Membre d'Honneur
-l de ls donne la taille des fichiers en octets
-s de ls donne taille en nombre de blocs
Normal de ne pas obtenir la même taille, Quand un envoie un fichier de 1 octet sur disque, ce sont des blocs entiers qui sont réservés. Pour être efficace, un système de fichiers ne travaille jamais à l'octet mais avec des blocs uniformes...
2° Avec ton script tu ne vois rien, tu retrouves le total de du, soit 6Go, d'accord. Mais quid des 26Go sur 28Go qui font 100% ?
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
magnux77 :
1° ls
-l de ls donne la taille des fichiers en octets
-s de ls donne taille en nombre de blocs
Normal de ne pas obtenir la même taille, Quand un envoie un fichier de 1 octet sur disque, ce sont des blocs entiers qui sont réservés.
-l de ls donne la taille des fichiers en octets
-s de ls donne taille en nombre de blocs
Normal de ne pas obtenir la même taille, Quand un envoie un fichier de 1 octet sur disque, ce sont des blocs entiers qui sont réservés.
OK pour la différence entre -l et -s.
Mais du -Pxs ne trouve pas le même résultat alors qu'il donne des tailles en nombres de blocs de 1024o.
Citation :
2° Avec ton script tu ne vois rien, tu retrouves le total de du, soit 6Go, d'accord. Mais quid des 26Go sur 28Go qui font 100% ?
Si, quand-même. Si il y avait un répertoire anormalement rempli, il serait comptabilisé. Donc le fait que je trouve à peu près le même résultat qu'avec du m'indique que ça n'est pas un fichier identifiable par ls.
Et puis je peux pas taper un ls à la main dans les milliers de répertoires de / !!
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Papoteur :
Certains fichiers/répertoires pourraient être masqués par des points de montage, genre /home, /tmp
Et oui, c'était le piège !
En fait, j'ai fait l'installation de ce PC à distance connecté sur une clé USB. J'ai cloné une installation que j'avais chez moi sur le disque du PC.
A ce moment là, la partition /dev/sda6 était montée sur /mnt/slash et j'ai utilisé /mnt/slash/tmp pour y transférer de gros fichiers.
Quand le PC a booté sur sda6, il a masqué /tmp par tmpfs. La disparition de mes fichiers ne m'a pas étonné, je pensais qu'il avait fait le ménage.
Mais il n'y avait déjà plus beaucoup de place sur le disque.
Et puis les log ont grossi dans /var, et / est arrivé à saturation.
Donc je me suis reconnecté sur la clé USB et j'ai retrouvé les fautifs :
Code BASH :
# ll /mnt/slash/tmp/ total 20568528 -rw-r--r-- 1 root root 17158307840 oct. 1 14:24 PC-windows.tar -rw-r--r-- 1 root root 65 sept. 28 23:26 PC-windows.tar.sha1 -rw-r--r-- 1 root root 3903848448 oct. 1 15:50 Mageia-6-x86_64-DVD.iso -rw-r--r-- 1 root root 66 oct. 1 14:30 Mageia-6-x86_64-DVD.iso.sha1
Après suppression des fichiers et redémarrage sur sda6, tout est rentré dans l'ordre :
Code BASH :
# df Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur devtmpfs 1,9G 0 1,9G 0% /dev tmpfs 1,9G 0 1,9G 0% /dev/shm tmpfs 1,9G 824K 1,9G 1% /run /dev/sda6 28G 6,6G 20G 26% / tmpfs 1,9G 0 1,9G 0% /sys/fs/cgroup tmpfs 1,9G 8,0K 1,9G 1% /tmp /dev/sda8 133G 69G 58G 55% /home tmpfs 386M 0 386M 0% /run/user/0 tmpfs 386M 12K 386M 1% /run/user/1000
Un grand merci à tous. J'ai appris plein de choses intéressantes.
Et une image de filelight, supernavigateur dans le système de fichiers :
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Papoteur :
Et qu'est qu'on dit ?
Ça par exemple mais c'est déjà fait :
zwykx :
Un grand merci à tous. J'ai appris plein de choses intéressantes.
Sinon j'ai encore plein de problèmes à vous soumettre mais c'est pour plus tard
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie