Espace disque plein

Bonjour à tous,

Je suis un novice et j’ai essayé de résoudre le problème par moi-même mais je suis perdu…

Je n’ai presque plus d’espace disque et il me dit que /dev/root est bientôt plein.

Lorsque j’exécute df -h j’obtiens :

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/root 30G 28G 869M 97% / devtmpfs 486M 0 486M 0% /dev tmpfs 98M 196K 97M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 195M 0 195M 0% /run/shm tmpfs 297M 0 297M 0% /tmp

J’ai ensuite cherché pour trouver les fichiers les plus volumineux, avec la commande find / -type f -size +20M -exec ls -lh {} ; | awk ‘{ print $NF ": " $5 }’ :

find: "/System Volume Information": Erreur d'entrée/sortie find: "/proc/13558/task/13558/fd/5": Aucun fichier ou dossier de ce type find: "/proc/13558/task/13558/fdinfo/5": Aucun fichier ou dossier de ce type find: "/proc/13558/fd/5": Aucun fichier ou dossier de ce type find: "/proc/13558/fdinfo/5": Aucun fichier ou dossier de ce type /usr/lib/arm-linux-gnueabihf/libicudata.so.52.1: 23M /var/log/btmp.1: 81M /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_source_Sources: 31M /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_binary-armhf_Packages: 32M /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_i18n_Translation-en: 22M /var/cache/apt/srcpkgcache.bin: 22M /var/cache/apt/pkgcache.bin: 22M /swapfile1: 512M

Mais je ne trouve pas grand chose qui pourrait expliquer l’occupation de ces 30 Go… du coup je ne sais plus trop quoi faire…

Merci d’avance pour votre soutien

Pour éclairer une route obscure à qui passera ensuite, le /home est où ? Sur le même point de montage que / ?

Si oui, c’est du côté de tes fichiers persos qu’il faut faire le ménage…

Tu peux aussi lancer ncdu (tu devrais pouvoir l’installer, il est petit et marche en console) qui permet de voir la place occupée simplement

aptitude clean, tu l’as fait ?

Edit: que vient faire le “system volume information erreur d’entrée sortie” dans tes infos ?

A exécuter en root pour une première analyse de l’occupation de la racine :

mount --bind / /mnt du -shc /mnt/* umount /mnt

Merci pour vos réponses.

J’ai bien exécuté aptitude clean mais cela n’a rien changé.

J’ai installé ncdu, il me donne le même résultat :

ncdu 1.10 ~ Use the arrow keys to navigate, press ? for help --- / --------------------------------------------------------------------------------------------------------------------------------------- 512.0MiB [##########] swapfile1 340.6MiB [###### ] /usr 283.6MiB [##### ] /var 79.4MiB [# ] /lib 6.4MiB [ ] /boot 4.9MiB [ ] /sbin 4.7MiB [ ] /bin 4.0MiB [ ] /etc 3.5MiB [ ] /root 200.0KiB [ ] /run 140.0KiB [ ] /home e 16.0KiB [ ] /lost+found e 4.0KiB [ ] /tmp e 4.0KiB [ ] /srv e 4.0KiB [ ] /opt e 4.0KiB [ ] /mnt e 4.0KiB [ ] /media 0.0 B [ ] /sys . 0.0 B [ ] /proc 0.0 B [ ] /dev ! 0.0 B [ ] System Volume Information

/home est censé être sur le même point de montage que / mais je ne sais pas comment le vérifier désolé.

J’ai également exécuté ces commandes en tant que root, voici le résultat…

mount --bind / /mnt root@usopp / # du -shc /mnt/* 4.8M /mnt/bin 6.5M /mnt/boot 12K /mnt/dev 4.0M /mnt/etc 140K /mnt/home 80M /mnt/lib 16K /mnt/lost+found 4.0K /mnt/media 4.0K /mnt/mnt 4.0K /mnt/opt 4.0K /mnt/proc 3.5M /mnt/root 24K /mnt/run 5.0M /mnt/sbin 4.0K /mnt/srv 513M /mnt/swapfile1 4.0K /mnt/sys du: impossible d'accéder à « /mnt/System Volume Information »: Erreur d'entrée/sortie 4.0K /mnt/tmp 341M /mnt/usr 284M /mnt/var 1.3G total 1 root@usopp / # umount /mnt :( root@usopp / #

Qu’est-ce que c’est que ce répertoire “System Volume Information” illisible ? Ce n’est pas spécifique à Windows/NTFS ?
Quel est le système de fichiers de la racine, à vérifier avec [mono]df -T /[/mono] ?

# df -T / Sys. de fichiers Type blocs de 1K Utilisé Disponible Uti% Monté sur /dev/root ext4 30656012 28469772 922156 97% /

Ah peut-être que c’est à cause de cela. Il s’agit d’une carte SD et j’avais essayé de récupérer certains fichiers en la connectant sur un système Windows NTFS. J’avais alors utilisé le logiciel Ext2fsd pour pouvoir accéder aux partitions ext4. Windows a du créer ou modifier quelque chose sur la carte à ce moment-là.

Tant pis pour moi je ne le referai plus, merci en tout cas pour votre aide

Cela explique la présence du répertoire “System Volume Information”, mais pas pourquoi il n’y a presque plus d’espace libre alors que le parcours de l’arborescence montre une occupation beaucoup plus faible (apparamment il y a juste un système minimal et aucune donnée ?).

Les hypothèses classiques qui me viennent à l’esprit sont :

  • contenu caché sous un point de montage : infirmé avec l’analyse après le “bind mount” sur /mnt.
  • système de fichiers à fonctionnalités “spéciales” occupant de l’espace (snapshot, multi-volume…) : ce n’est pas le cas d’ext4 à ma connaissance.
  • fichiers encore ouverts et supprimés (peut arriver aux fichiers logs) n’apparaissant plus dans l’arborescence mais occupant encore l’espace disque tant qu’ils restent ouverts par un processus : [mono]lsof | grep deleted[/mono] les listera avec la mention “deleted”, et un simple reboot devrait libérer l’espace occupé.
  • corruption du système de fichiers : à vérifier avec [mono]fsck[/mono] suivi du nom de la partition mais depuis un autre système ou dans le shell de l’initramfs (si l’architecture armhf en utilise un et la console est disponible) puisque le volume ne doit pas être monté.

Il y avait effectivement très peu de données, j’y avais juste installé de quoi faire un petit serveur web (apache+mysql à ce stade).

Je n’ai pas la possibilité de faire le fsck depuis un autre système, alors j’ai tenté le shutdown -rF now pour forcer le fsck au reboot, mais je ne connais pas le résultat du coup.

Pour le lsof | grep deleted il y a pas mal de résultats, et ces résultats sont toujours listés même après le reboot, je ne sais pas si c’est normal ou non.
Je n’ai pas tout copié car la liste contient encore de nombreux mysql :

# lsof | grep deleted apache2 1138 root 9u REG 179,2 0 72 /tmp/.ZendSem.WQ933m (deleted) apache2 1138 root 10w REG 0,14 0 2261 /run/lock/apache2/mpm-accept.1138 (deleted) apache2 1142 www-data 9u REG 179,2 0 72 /tmp/.ZendSem.WQ933m (deleted) apache2 1142 www-data 10w REG 0,14 0 2261 /run/lock/apache2/mpm-accept.1138 (deleted) apache2 1143 www-data 9u REG 179,2 0 72 /tmp/.ZendSem.WQ933m (deleted) apache2 1143 www-data 10w REG 0,14 0 2261 /run/lock/apache2/mpm-accept.1138 (deleted) apache2 1144 www-data 9u REG 179,2 0 72 /tmp/.ZendSem.WQ933m (deleted) apache2 1144 www-data 10w REG 0,14 0 2261 /run/lock/apache2/mpm-accept.1138 (deleted) apache2 1145 www-data 9u REG 179,2 0 72 /tmp/.ZendSem.WQ933m (deleted) apache2 1145 www-data 10w REG 0,14 0 2261 /run/lock/apache2/mpm-accept.1138 (deleted) apache2 1146 www-data 9u REG 179,2 0 72 /tmp/.ZendSem.WQ933m (deleted) apache2 1146 www-data 10w REG 0,14 0 2261 /run/lock/apache2/mpm-accept.1138 (deleted) mysqld 1742 mysql 4u REG 179,2 0 88 /tmp/ib9x3BKN (deleted) mysqld 1742 mysql 5u REG 179,2 0 98 /tmp/ib62Gdzr (deleted) mysqld 1742 mysql 6u REG 179,2 0 226 /tmp/ibdZZup5 (deleted) mysqld 1742 mysql 7u REG 179,2 0 421 /tmp/ibFQR7cq (deleted) mysqld 1742 mysql 11u REG 179,2 0 497 /tmp/ib22ir3j (deleted) mysqld 1742 1744 mysql 4u REG 179,2 0 88 /tmp/ib9x3BKN (deleted)

Tous ces fichiers sont de taille nulle. D’autre part, les fichiers dans /run/lock ne sont pas sur la racine puisque /run/lock est un système de fichiers temporaire en mémoire (tmpfs) comme on peut le voir dans la sortie de [mono]df[/mono]. Le périphérique 0,14 associé à ces fichiers correspond à un montage sans périphérique (un système de fichiers tmpfs n’est pas un périphérique, contrairement à un disque ou une partition).

Par contre il me semble y avoir une incohérence concernant les fichiers dans /tmp : toujours d’après [mono]df[/mono], /tmp est aussi un tmfps mais le périphérique associé à ces fichiers dans la sortie de [mono]lsof[/mono] est 179,2 qui correspond à /dev/mmcblk0p2, 2e partition de la première carte SD/MMC. Je suppose que c’est la partition racine.

De toute façon ces fichiers sont de taille nulle, ce ne sont pas eux qui occupent l’espace. Et si tu arrêtes apache et mysql, ils devraient disparaître et si l’occupation de la racine ne diminue pas, ils sont hors de cause.

Il ne reste que ma dernière hypothèse, une incohérence du système de fichiers. Tu n’as pas une autre machine équipée d’un lecteur de carte SD sur laquelle tu peux lancer un système Linux quelconque (live) ? Sinon, as-tu une console physique sur ton système ARM et à quel stade ?