¿Qué está comiendo mi espacio en disco?

Estoy ejecutando Linux Mint 14 Nadia. La partición de Linux tiene 10G. Cuando se inicia el sistema, duinforma un 80% de uso. Luego, el uso crece lentamente hasta alcanzar el 100% y el sistema queda inutilizable. (Puede ocurrir en el orden de días o semanas). Después del reinicio, el uso se restablece al 80%.

Lo más extraño de todo es que duno muestra ningún cambio.

Aquí está la salida de esos comandos (Windows y las particiones de unidades externas se eliden):

# --- Just after reboot ---

$ df -h     
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  7.3G  2.0G  80% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M  288K  437M   1% /run/shm
none            100M   12K  100M   1% /run/user

$ sudo du -x   -d1 -h /
186M    /opt
512M    /var
11M /sbin
556K    /root
1.3G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
60K /tmp
9.1M    /bin
4.0K    /srv
7.3G    /            # <-- note this


# --- After some time ---

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  9.1G  199M  98% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M   27M  411M   7% /run/shm
none            100M   28K  100M   1% /run/user

$  sudo du -x   -d1 -h /
186M    /opt
511M    /var
11M /sbin
556K    /root
1.4G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
520K    /tmp
9.1M    /bin
4.0K    /srv
7.3G    /              # <-- note this

(Nota: uso hibernación. Después de la hibernación, el uso permanece igual y, después de reiniciar, se restablece al 80%).

¿Cómo hago un seguimiento de lo que come el espacio?

He leído esta pregunta . Todavía estoy en la oscuridad. ¿Cómo averiguo qué programa es responsable de este comportamiento?

Después de editar : lo encontré. El espacio lo reclama el registro del núcleo, que es visto por dmesg. Se llena porque mi máquina genera errores a una velocidad de 5 por segundo. (Está relacionado con este error ). Deje que los futuros lectores con un problema similar, llenando lentamente el espacio del disco que no se ve du, no olvide intentar dmesgbuscar la causa.

Ejecución repetida de

sudo du -x   -d1 -h /

(en el árbol de directorios) debería decirle dónde se consume el espacio. Eso probablemente explica sin más investigación qué aplicación está causando eso.

archivos invisibles

Si duno muestra estos archivos, una de las posibilidades son los archivos eliminados. Un archivo (o más bien: su nombre, es decir, su entrada en un directorio) se puede eliminar mientras el archivo todavía está en uso. Siempre que haya un descriptor de archivo válido que apunte a este archivo, cubrirá el espacio en el volumen (si no es un archivo vacío ...).

cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0

Puede encontrar estos archivos con find:

find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n     %l\n' 2>/dev/null

Puede ser un solo archivo enorme o un grupo de archivos más pequeños que causan su problema. Hay alrededor de 30 archivos de este tipo en mi sistema ahora (pertenecientes a solo cinco procesos). ls -lmuestra el tamaño de estos archivos, pero parece que no es posible obtener este valor find.

Después de finalizar el proceso, el espacio vuelve a estar disponible para el sistema de archivos ( df).

Usa algo como

lsof -s | grep deleted | sort -k 8

para ver qué procesos mantienen abiertos los archivos eliminados. Los campos importantes son el segundo (PID) y el octavo (tercero desde el último; el tamaño del archivo).

(Preste atención a las líneas duplicadas, no las cuente dos veces. Verifique el PID y la ruta del archivo (último campo) o el número de inodo (penúltimo campo).)

Después de eso, si encuentra un proceso que probablemente sea el culpable, podemos ver cómo solucionarlo.

find / -size +10000k -print0 | xargs -0 ls -l -h

Use esto para encontrar recursivamente lo que está llenando más de 10MB + desde /(raíz) y mostrarlo con muchos detalles con ls -lin xargs. Si escribe 1000000 (2 ceros adicionales) puede obtener 1GB + por ejemplo.

du / -h --max-depth=1 | sort -h

También puede usar du, y simplemente profundizar en él manualmente.

Cuando esto sucede, siempre comienzo mi enfoque en ciertos subdirectorios. Con esto en mente, se presenta la estructura de FHS a la que se adhieren la mayoría de las distribuciones de Linux.

Primero mira adentro /var, seguido de /home.

$ sudo du -x -d1 -h /var  | sort -hr`

$ sudo du -x -d1 -h /home | sort -hr`

Puede limitar su enfoque a subdirectorios dentro de cualquiera de esas ubicaciones también. Una vez que ha agotado la búsqueda allí, generalmente me muevo a /root, y finalmente a los subdirectorios restantes en /.

Si se trata de una distribución basada en Red Hat, el caché que yumutiliza para realizar actualizaciones podría estar consumiendo una gran cantidad de espacio. Puede usar este comando para borrarlo:

$ yum clean packages

Otras distribuciones que el uso aptpuede hacer algo similar, apt-get clean.

También ejecuté este comando en la parte superior de su /directorio, esta ubicación a veces puede convertirse en la fuente de archivos de registro extraviados.

$ ls -la /

¡Presta especial atención a los archivos de puntos! Cosas nombradas .blah, por ejemplo.

timeshift Estaba comiendo mi disco.

sudo timeshift -delete--all

Recuperado 50Gb.

Tengo casi la misma situación.

En mi caso, la razón fue VMware. Uno de los otros VMwares en la misma máquina, consumió los espacios en disco. Es por eso que mi uso de espacio en disco fue del 100%.

Después de eliminar archivos grandes del VMware del vecino, funciona correctamente.