df muestra todo el espacio ocupado, pero du no suma

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 inodes en un sistema 450G ext4 compilando y construyendo 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, tengo menos de 1 GB de espacio libre. No hay nada en esta máquina aparte de lo que se necesita para construir Android. He realizado 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 informan de esa manera. Eliminé un montón de archivos temporales y tenía unos 40 GB "liberados". Un par de horas más tarde, simplemente inactivo, volví a menos de 1GB gratis.

Ejecutar 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 Visual Disk Usage Analyzer, demuestro que en realidad solo estoy usando unos 35GB más o menos. El 98.7% del espacio utilizado está en /home/eric, pero duno se suma a eso. La discrepancia es entre /home/ericy/home/eric/android

He leído las preguntas relevantes aquí y en SO y, por lo general, sugieren que se trata de archivos eliminados en procesos abiertos. Reinicié en una unidad flash para ejecutar esta prueba, por lo que no deberían 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 configurar este sistema de una manera diferente? Prefiero no hacer otra limpieza e instalación, pero necesito un sistema de compilación de Android sostenible.

SEGUIMIENTO : tuve que instalar la instalación la semana pasada y reinstalé 12.04 para poder hacer el trabajo. A medida que reviso las compilaciones de Android nuevamente esta semana, vigilaré atentamente el uso del disco y daré información aquí a medida que aprenda más.

Gracias

En Oracle Linux sucede cuando tiene archivos (muchos / grandes) que se eliminan pero aún se abren mediante un proceso en ejecución. A continuación, ayuda a detener los procesos o reiniciar la máquina.

Recientemente me encontré con esto, y en mi caso fscknecesitaba ser ejecutado.

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

Antes de llegar al extremo ..... baje el sistema al modo de usuario único y realice un fsck COMPLETO (quiero decir completo fsck -f /dev/sda5) del sistema de archivos y vea lo que muestra. Es posible que encuentre el espacio como porciones de áreas problemáticas en su disco o que no coincida entre lo que está asignado y lo que está presente en el disco.

Podemos hacer una prueba, dudice que tiene 10GB de espacio libre, mientras que dfdice 300 MB, ¿puede escribir un archivo (o varios archivos) con un tamaño de, digamos, 2 GB? Si puede, eso significa que df simplemente está mal (y en realidad no hay ningún problema de "espacio perdido"). Si no, entonces duestá mal (lo que será interesante).

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.

Arrancar usando systemrescuecd 3.3.0 y verificar nuevamente mostró una diferencia de menos de 1 GiB.

Dejando la partición y el sistema de archivos (es ext4) sin cambios, quité los directorios de ubuntu y instalé Debian 7.0. Nuevamente, la diferencia entre du y df fue <1 GiB.

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

De 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

La imagen informados le está diciendo dónde se está utilizando el espacio: /home/eric. Parece que tiene un archivo muy grande 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+ Hen Nautilus) y ordene por tamaño de archivo.

Esto es causado frecuentemente por 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, habiendo verificado que no se están utilizando como puntos de montaje ( cat /proc/mountso df -h).