Le lecteur racine Ubuntu manque d'espace, je ne trouve pas la source via du ou lsof

10

Le lecteur racine sur une machine Ubuntu 15.10 est presque à court d'espace, mais je ne trouve pas la source. Le disque qui manque d'espace est de sdb2313 Mo sur 51 Go. Le système de fichiers est ext4.

Voici la sudo du -h / --max-depth=1sortie:

Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           789M  9.4M  780M   2% /run
/dev/sdb2        51G   48G  313M 100% /
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sdb1       511M  3.4M  508M   1% /boot/efi
tmpfs           789M  8.0K  789M   1% /run/user/1000
/dev/sda1       239G  122M  239G   1% /media/DATA

Mais je ne trouve aucun fichier volumineux. L'utilisation totale ne /semble être que de 3,4 G. Voici la sortie de sudo du -h / --max-depth=1:

4.0K    /mnt
188K    /tmp
406M    /home
339M    /var
8.1M    /etc
361M    /lib
du: cannot access ‘/proc/7626/task/7626/fd/4’: No such file or directory
du: cannot access ‘/proc/7626/task/7626/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/7626/fd/3’: No such file or directory
du: cannot access ‘/proc/7626/fdinfo/3’: No such file or directory
0    /proc
13M    /bin
du: cannot access ‘/run/user/1000/gvfs’: Permission denied
9.4M    /run
1.6M    /root
4.0K    /lib64
16K    /lost+found
0    /sys
1.1M    /media
12K    /dev
222M    /opt
2.0G    /usr
62M    /boot
9.5M    /sbin
4.0K    /cdrom
8.0K    /srv
3.4G    /

J'ai trouvé une question similaire ici: Hors de l'espace disque, quelle est la source?

Dans ce cas, il semble que le problème soit dû à un journal supprimé qui, d'une manière ou d'une autre, n'a pas été fermé par un processus en cours, et la façon de le trouver était de s'exécuter sudo lsof | grep deleted. Dans mon cas, la sortie est

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.

En outre, le problème persiste après le redémarrage du système, il est donc peu probable que ce soit la cause.

Une autre solution suggérée consiste à démonter /var/lib/ureadahead/debugfs, mais j'hésite à le faire.

Quoi d'autre pourrait-être faux?

ubuntu disk-space-utilization

— biggvsdiccvs
source

faire un redémarrage. il y a des fichiers supprimés mais verrouillés.

— Ipor Sircer

J'ai essayé, mais rien n'a changé.

— biggvsdiccvs

1

Recherchez des erreurs dans le système de fichiers et effectuez une mise à jour vers une version d'Ubuntu prise en charge.

— Michael Hampton

6

exécutez simplement "du -sh *" lorsque vous êtes dans le dossier racine. Ne pas utiliser --max-depth flag

— Orphans

1

@Orphans semble que je n'ai pas vu le *niché contre "

— ypu

21

Eh bien, ce n'est qu'une supposition, mais cela peut fonctionner: je pense que l'utilisateur oublie une fois de monter au /dev/sda1fur /media/DATAet à mesure que toutes les données ont été écrites à la /dev/sdb2place de /dev/sda1.

Pour vérifier cela, veuillez démonter /media/DATAet vérifier les fichiers et dossiers sous ce chemin.

— Fedor Dikarev
source

Merci, c'est ça! Sauf que je pense que cela aurait pu être une mauvaise connexion de lecteur plutôt que quiconque oublie de monter quoi que ce soit. Toute cette configuration n'est pas fiable et je ne sais pas comment ce lecteur est monté /media/DATA- ce n'est pas le cas /etc/fstab.

— biggvsdiccvs

Si vous ne voulez pas démonter le système de fichiers (par exemple, si vous ne voulez pas arrêter les processus qui l'utilisent), vous pouvez utiliser un montage de liaison pour voir (et supprimer) les fichiers cachés par le montage.

— Johnny

7

J'utilise régulièrement 'ncdu' pour cela, il est assez petit pour qu'il soit toujours installé.

sudo apt-get install ncdu

Assurez-vous de l'exécuter en tant que root ou via sudo:

sudo ncdu /

— Roy Jacobs
source

1

N'aurait pas aidé dans ce cas cependant.

— Gerald Schneider

2

Lorsque vous voulez savoir où l'espace est utilisé dans un système de fichiers particulier, vous pouvez utiliser cette commande pour trouver les 20 plus grands répertoires, ce qui peut vous aider à localiser où l'espace le plus utilisé est utilisé,

du -m / |sort -n |tail -20

Mais le système de fichiers racine est plus difficile, car tous les systèmes de fichiers sont montés sur root. Mais l'argument -x (--one-file-system) ne signalera que le système de fichiers souhaité,

du -m -x / |sort -n |tail -20

— ChuckCottrill
source

1

df -h *.*

Pourrait aider.

Parcourt les répertoires et résume les octets utilisés.

— steJav
source