El disco se llena lentamente pero no hay cambios visibles en el tamaño del archivo

df

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

Ese 77% fue solo un 60% ayer y se completará hasta el 100% en unos días.

He estado monitoreando tamaños de archivos por un tiempo ahora:

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

Me ha estado dando (más o menos) los mismos números todos los días. Ese total de 14G es menos de la mitad del tamaño del disco. ¿A dónde va el resto?

Mi conocimiento de Linux no va mucho más profundo.

¿Es posible que los archivos no aparezcan aquí? ¿Es posible tener espacio asignado de alguna otra manera?

Si hay un crecimiento invisible en el espacio en disco, un posible culpable sería eliminar archivos. En Windows, si intenta eliminar un archivo abierto por algo, obtiene un error. En Linux, el archivo se marcará como eliminado, pero los datos se retendrán hasta que la aplicación lo suelte. En algunos casos, esto se puede usar como una forma ordenada de limpiar después de usted mismo : los bloqueos de la aplicación no evitarán que se limpien los archivos temporales.

Para ver los archivos eliminados y aún usados:

lsof -b 2>/dev/null | grep deleted

Es posible que tenga una gran cantidad de archivos eliminados; eso en sí mismo no es un problema. Un solo archivo eliminado que se está volviendo grande es un problema.

Un reinicio debería solucionar esto, pero si no desea reiniciar, verifique las aplicaciones involucradas (primera columna en la lsofsalida) y reinicie o cierre las que tengan un aspecto razonable.

Si alguna vez ves algo como:

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

Cuando la aplicación y los archivos eliminados son iguales, eso probablemente significa que la aplicación se actualizó. Puede ignorarlos como fuente de gran uso de disco (pero aún así debe reiniciar el programa para que se apliquen las correcciones de errores).

Los archivos /dev/shmson objetos de memoria compartida y no ocupan mucho espacio en el disco (creo que un número de inodo como máximo). También se pueden ignorar con seguridad. Los archivos nombrados vteXXXXXXson archivos de registro de un emulador de terminal basado en VTE (como GNOME Terminal, Terminator, etc.). Estos podrían ser grandes, si tiene una ventana de terminal abierta con muchas (y quiero decir muchas ) cosas que salen.

Para agregar a la excelente respuesta de muru:

• df muestra el tamaño en el disco,
• y du muestra el tamaño total del contenido de los archivos.

Tal vez lo que no ve con du es la aparición de muchos, muchos archivos pequeños ... (mire en la última columna de df -iy vea si el número de inodos (es decir, de archivos) también aumenta mucho las horas extras)

Si tiene, digamos, 1'000'000 (1 millón) de archivos pequeños de 1 byte, ducontará como 1'000'000 bytes en total, digamos 1Mb (... puristas, por favor, no se avergüence)

Pero en el disco, cada archivo está compuesto de 2 cosas:

• 1 inodo (apuntando a los datos del archivo), y ese inodo por sí solo puede ser 16kb (!),
• Y los datos de cada archivo (= el contenido del archivo) se colocan en bloques de disco, y esos bloques no pueden contener datos de varios archivos (generalmente ...), por lo que su 1 byte de datos ocupará al menos 1 bloque

Por lo tanto, un millón de archivos de 1 byte ocuparán el 1'000'000'000 * size_of_a_blockespacio total para los datos, más 1'000'000'000 * size_of_an_inodeel tamaño del inodo ... Eso puede equivaler a varios Gb de uso de disco para 1 millón de archivos de "1 byte".

Si tiene bloques de 1024 bytes y otros 256 bytes de tamaño de inodo, sus archivos de 1'000'000 serán reportados como aproximadamente 1Mb du, ¡pero contarán como aproximadamente 1.25Gb en el disco (como se ve df)! (o incluso 2 Gb si cada inodo también tiene que estar en 1 bloque de disco dedicado ... No sé si ese es el caso)

Si se /dev/vda1está llenando, puede ser causado por Jenkins o Docker (o etc.) y es posible que deba usar el lsofcomando para limpiar los registros y establecer su tamaño .