Sistema de archivos de Linux; diferencia en el cálculo del tamaño usando df y du

Cuando lo ejecuto df, muestra que el dispositivo raíz está lleno.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.4G     0 100% /

Miré el inodeuso y hay bastante espacio disponible para el dispositivo raíz

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1               640K    103K    538K   16% /

Sin embargo, cuando ejecuto el ducomando, se muestra he utilizado solamente 2Gde 9.9G.

ip-XXX-XXX-XXX-XXX:/$ du -xh --max-depth=1
14M ./etc
4.0K ./mnt
96K ./tmp
3.5M ./bin
0   ./sys
964K ./boot
4.0K ./srv
0   ./dev
55M ./lib
25M ./root
1.1G ./usr
4.0K ./opt
846M ./var
4.3M ./sbin
23M ./home
16K ./lost+found
0   ./proc
2.0G .

Simplemente me está volviendo loco e interesante también. Este es un gran problema para nosotros ya que el disco raíz /está lleno y algunas de las funciones de nuestro sitio están fallando.

Por favor, ayúdame a resolver (también entiendo) este problema.

Gracias.

Cuando los archivos se eliminan en * nix, continúan viviendo en el disco (y ocupan espacio en el disco) mientras un proceso los tenga abiertos. Es bastante común aprovechar esto para "asegurar" los archivos temporales al crearlos con un tamaño pequeño, eliminarlos y luego usar el archivo eliminado para almacenar datos sin tener que preocuparse de que otros procesos (fácilmente) tengan acceso a ellos, por lo que la cantidad de espacio en los archivos eliminados puede crecer bastante si, por ejemplo, una base de datos temporal o una sesión de edición multimedia se maneja de esta manera. Otra posibilidad de cómo podría tener tanto espacio "perdido" sería si el sistema se hubiera actualizado (varias veces) sin reiniciar o reiniciar programas, lo que daría como resultado que todas sus bibliotecas .so antiguas se mantuvieran abiertas por programas que se iniciaron antes de actualizar y todavía se están ejecutando.

dfve el espacio utilizado por estos archivos porque solo mira cuánto espacio está asignado en el dispositivo, pero duno los ve porque no hay entradas de directorio correspondientes.

El espacio usado "oculto" como este solo se puede liberar cuando los procesos que han eliminado archivos abiertos los cierran. Puede encontrar estos procesos con el fusercomando y finalizarlos (o, para muchos demonios, enviar una señal diciéndoles que cierren y vuelvan a abrir los archivos abiertos).

Ha habido ocasiones en que si el disco se llena, puede confundirse hasta que se reinicie / vuelva a montar que el disco todavía está lleno, incluso cuando haya eliminado una carga de archivos.

Por mi parte, simplemente reinicié syslogd para recuperar el espacio en disco. ¡Me faltaban 3 GB! Mi servidor estuvo funcionando durante 250 días.

Hay una manera de limpiar el espacio sin reiniciar la aplicación. Aquí están los detalles:

1. Supongamos que tiene un proceso fooejecutándose y creando un archivo de 2 GB llamado abc.log. Ahora digamos que este abc.log es eliminado por otra persona.

2. Obtener foopid (digamos 123). Entonces /proc/123/fdmostrará una lista de descriptores de archivos abiertos por foo. Uno con abc.log se mostrará como eliminado. Digamos que fdabs.log es 111. Si ejecuta less /proc/123/fd/111, todavía le mostrará todos esos 2 GB de datos.

3. Ejecutar echo " " > /proc/123/fd/111. Esto sobrescribirá el contenido con una cadena vacía. Después de este comando, si lo prueba df, mostrará 2 GB adicionales recuperados limpiando abc.log.

Eso es. Intenté esto en CentOS y funciona.