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

8

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.

— Rakesh Sankar
fuente

2

Consulte la confusión sobre el espacio libre en disco de Linux y otras +df +dupreguntas en Unix y Linux .

— Gilles 'SO- deja de ser malvado'

@Gilles como dijiste, corrí du -x /y veo que solo se usa 2G y calculé el tamaño del inodo que es 160M. Me ayudó a entender las cosas, pero solo quiero resolver este problema.

— Rakesh Sankar

¿Corriste ducomo root? De lo contrario, solo puede informar sobre los archivos a los que puede acceder.

— Gilles 'SO- deja de ser malvado'

@Gilles Estoy corriendo comoroot

— Rakesh Sankar

No tengo mucho que agregar aquí aparte del gran ncduprograma, que ayuda a visualizar el uso del disco.

— Rob

4

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).

— Dave Sherohman
fuente

gracias, buena información, algo (más) que entiendo hoy. Pero para encontrar un hiddenespacio usado, trato de ejecutar el fusercomando para ver todos los archivos que están siendo utilizados por un proceso pero desvinculados; no pude encontrar ninguno. ¿Tienes algún comando o dirección que me lleve a encontrarlo? Este es el comando que usofuser -v -a /

— Rakesh Sankar

Tuve que reiniciarlo para eliminar el espacio oculto, pero no pude encontrar una solución adecuada para eliminar esos archivos ocultos.

— Rakesh Sankar

1

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.

— BugFinder
fuente

No puedo reiniciar ya que es un sitio de producción. Pero estoy buscando una solución que pueda ayudarme a encontrar estos espacios ocultos y recuperarlos.

— Rakesh Sankar

Tal vez la producción, pero a veces un reinicio es la única respuesta. Ese es el desafortunado problema de ser su disco raíz y todo su sistema operativo está en él. Es por eso que muchos recomiendan el uso de tmp, var, home, etc. en otros discos, ya que luego se pueden volver a montar. Parece ser más común que el sistema operativo no se dé cuenta de que el espacio está disponible para el disco raíz.

— BugFinder

1

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

— Vincent Martineau
fuente

0

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

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.
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.
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.

— Kaustubh Sathe
fuente

Esto es algo útil para saber. Pero no es una respuesta a la pregunta.

— Isaac Rabinovitch

lo siento, mi respuesta estaba más destinada a limpiar el espacio en disco si conoces la identificación del proceso que eliminó el archivo. Para este caso específico, debe revisar todos los archivos en / proc / [0-9] * / fd, seleccionar los eliminados y seguir la lógica mencionada anteriormente.

— Kaustubh Sathe

Si tiene curiosidad por saber qué archivo estaba causando la fuga de espacio en disco, limpie el archivo eliminado a la vez, verifique la salida de df cada vez y registre esta información.

— Kaustubh Sathe