Ubuntu root drive quedando sin espacio, no puedo encontrar la fuente a través de du o lsof

La unidad raíz en una máquina Ubuntu 15.10 está casi sin espacio, pero no puedo encontrar la fuente. La unidad que se está quedando sin espacio es sdb2313M de 51G disponibles. El sistema de archivos es ext4.

Aquí está la sudo du -h / --max-depth=1salida:

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

Pero no puedo encontrar ningún archivo grande. El uso total en /parece ser solo 3.4 G. Aquí está el resultado 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    /

Encontré una pregunta similar aquí: sin espacio en disco, ¿cuál es la fuente?

En ese caso, parece que el problema fue causado por un registro eliminado que de alguna manera no fue cerrado por un proceso en ejecución, y la forma de encontrarlo fue ejecutarlo sudo lsof | grep deleted. En mi caso, la salida es

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

Además, el problema persiste después de reiniciar el sistema, por lo que es poco probable que esa sea la causa.

Otra solución sugerida es desmontar /var/lib/ureadahead/debugfs, pero dudo en hacerlo.

¿Qué más podría estar mal?

Bueno, es solo una suposición, pero puede funcionar: creo que ese usuario una vez se olvidó de montar /dev/sda1como /media/DATAy todos los datos se escribieron en /dev/sdb2lugar de /dev/sda1.

Para verificar esto, desmonte /media/DATAy verifique los archivos y carpetas bajo esta ruta.

Regularmente uso 'ncdu' para eso, es lo suficientemente pequeño como para instalarlo.

sudo apt-get install ncdu

Solo asegúrate de ejecutarlo como root o mediante sudo:

sudo ncdu /

Cuando desee saber dónde se usa el espacio en un sistema de archivos en particular, puede usar este comando para encontrar los 20 directorios más grandes, que pueden ayudarlo a ubicar dónde se usa la mayor cantidad de espacio,

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

Pero el sistema de archivos raíz es más difícil, porque todos los sistemas de archivos están montados en la raíz. Pero el argumento -x (--one-file-system) informará solo el sistema de archivos deseado,

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

df -h *.* 

Podría ayudar.

Atraviesa directorios y resume los bytes utilizados.