df muestra todo el espacio ocupado, pero du no se suma

22

Tengo un problema con Ubuntu 12.04 LTS. Esta es la segunda vez que encuentro este problema en las últimas 3 semanas. La primera vez se describe en esta pregunta cerrada en StackOverflow . La versión TL; DR es que logré usar todos los inodos en un sistema 450G ext4 que compila y construye la pila de Android menos de 20 veces.

Pensé que estaba resolviendo el problema reformateando el disco como XFS para que el almacenamiento de inodo pudiera crecer.

Esta mañana, después de hacer una compilación durante la noche, he perdido menos de 1 GB de espacio libre. No hay nada en esta máquina que no sea lo que se necesita para construir Android. He hecho 5 compilaciones totales en las fuentes de la plataforma. La compilación crea un montón de archivos, luego los elimino poco después con make clean . Realmente no tengo menos de 1 GB, pero las herramientas lo reportan de esa manera. Eliminé un montón de archivos temporales y tuve unos 40 GB "liberados". Un par de horas más tarde, al ralentí, volví a tener menos de 1 GB gratis.

La ejecución de Ubuntu desde una unidad flash devuelve lo siguiente para la partición ...

$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda5      468521456 468255460    265996 100% /media/f71c77eb-b4cc-

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda5      1691760 624214 1067546   37% /media/f71c77eb-b4cc-

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       447G  447G  260M 100% /media/f71c77eb-b4cc-

Aquí está la evidencia de que algo anda mal. Cuando ejecuto du (con y sin --apparent-size) o el Analizador de uso de disco visual, muestro que realmente solo uso aproximadamente 35GB más o menos. El 98.7% del espacio utilizado está en /home/eric , pero du no se suma a eso. La discrepancia es entre /home/eric y /home/eric/android

He leído las preguntas relevantes aquí y en SO y, por lo general, sugieren que se eliminen los archivos en procesos abiertos. Reinicié en una unidad flash para ejecutar esta prueba, por lo que no debería ser archivos abiertos. FWIW, / tmp está vacío.

¿Hay alguna herramienta que pueda instalar en una unidad flash para recuperar el espacio 'perdido'? Puedo intentar liberar memoria en el sistema y ejecutarlo allí, pero supongo que es mejor hacerlo desde una unidad flash.

¿Debo estar configurando este sistema de una manera diferente? Preferiría no hacer otra limpieza e instalación, pero necesito un sistema de compilación de Android sostenible.

SEGUIMIENTO : tuve que detener la instalación la semana pasada y reinstalé la versión 12.04 para poder realizar el trabajo. Mientras reviso las versiones de Android de esta semana, vigilaré atentamente el uso del disco y daré información aquí a medida que obtenga más información.

Gracias

    
pregunta Eric Cloninger 15.02.2013 - 22:03

7 respuestas

15

En Oracle Linux sucede cuando tienes (muchos / grandes) archivos que se eliminan pero aún se abren mediante un proceso en ejecución. Luego, la detención de los procesos o el reinicio de la máquina ayuda.

    
respondido por el Michel Samia 24.09.2014 - 15:34
3

Hace poco me encontré con esto, y en mi caso se necesitaba ejecutar fsck .

Hice touch /forcefsck && reboot y después de unos minutos, el servidor volvió a estar en línea y, de repente, mis 6 GB perdidos se liberaron.

    
respondido por el mpontillo 13.09.2016 - 21:02
1

Antes de ir demasiado lejos ... lleve el sistema al modo de usuario único y realice un fsck COMPLETO (realmente me refiero a fsck -f /dev/sda5 completo) del sistema de archivos y vea lo que muestra. Es posible que encuentre el espacio como partes de áreas problemáticas en su disco o discrepancia entre lo que está asignado y lo que está presente en el disco.

    
respondido por el mdpc 19.02.2013 - 21:46
1

Podemos hacer una prueba, du dice que tiene 10 GB de espacio libre, mientras que df dice 300 MB, ¿puede escribir un archivo (o varios archivos) con un tamaño de, por ejemplo, 2 GB? Si puede, eso significa que df es simplemente incorrecto (y en realidad no hay problema de "espacio perdido"). Si no, entonces du es incorrecto (lo que será interesante).

    
respondido por el user_1729 22.02.2013 - 23:39
1

No he encontrado la causa de este problema, pero es exclusivo de ubuntu 12.04.

Simplemente configurando un nuevo servidor, comencé con Ubuntu 12.04 y me encontré con esto; du mostró un uso de 111 GiB, mientras que df fue de alrededor de 170 GiB.

El arranque con systemrescuecd 3.3.0 y la verificación nuevamente mostraron una diferencia de menos de 1 GiB.

Sin cambiar la partición ni el sistema de archivos (es ext4), aparté los directorios de Ubuntu e instalé Debian 7.0. De nuevo, la diferencia entre du y df fue < 1 GiB.

Con ubuntu 10.04, en la misma partición y ext4 fs:

Desde df -m / ,

Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/sda2              2814679    407164   2264538  16% /

y de du -mx ,

tail -1 /root/diskuse 
406920  .

que está lo suficientemente cerca.

    
respondido por el user163269 31.05.2013 - 06:19
0

La imagen que publicaste te indica dónde se está utilizando el espacio: /home/eric . Parece que tienes un archivo muy grande allí que ocupa todo el espacio, o posiblemente una gran cantidad de archivos más pequeños. Abra su directorio de inicio, asegúrese de mostrar los archivos ocultos ( Ctrl + H en Nautilus) y ordene por tamaño de archivo.

    
respondido por el psusi 25.02.2013 - 16:19
0

Esto se debe con frecuencia a los archivos dentro de un directorio, que también tiene un sistema de archivos diferente montado en él. Una solución típica es arrancar con un disco de rescate, o en modo de usuario único, y vaciar los directorios, verificando que no se están utilizando como puntos de montaje ( cat /proc/mounts o df -h ).

    
respondido por el Tim Small 12.08.2017 - 08:07

Lea otras preguntas en las etiquetas