Pregunta Disco lleno, du dice diferente. ¿Cómo seguir investigando?


Tengo un disco SCSI en un servidor (hardware Raid 1), 32G, ext3 filesytem. df Me dice que el disco está 100% lleno. Si borro 1G esto se muestra correctamente.

Sin embargo, si corro un du -h -x / entonces du Me dice que solo se usan 12G (yo uso -x por algunas monturas de samba).

Entonces, mi pregunta no es sobre diferencias sutiles entre los comandos du y df, sino sobre cómo puedo averiguar qué causa esta gran diferencia.

Reinicié la máquina para un fsck que iba sin errores. Debo correr badblocks? lsof no me muestra archivos borrados abiertos, lost+found está vacío y no hay una declaración de advertencia / error / falla obvia en el archivo de mensajes.

No dude en solicitar más detalles de la configuración.


89
2018-05-30 12:29


origen


Esto está muy cerca de la pregunta: linux - du vs. df diferencia (serverfault.com/questions/57098/du-vs-df-difference). La solución era archivos bajo un punto de montaje como respondió OldTroll. - Chris Ting


Respuestas:


Compruebe si hay archivos ubicados debajo de los puntos de montaje. Con frecuencia, si monta un directorio (por ejemplo, un sambafs) en un sistema de archivos que ya tenía un archivo o directorios debajo, pierde la capacidad de ver esos archivos, pero aún así están consumiendo espacio en el disco subyacente. He tenido copias de archivos mientras estaba en modo de usuario único volcando archivos en directorios que no podía ver, excepto en modo de usuario único (debido a que otros sistemas de directorio se montan encima de ellos).


87
2018-05-30 12:35



Puede encontrar estos archivos ocultos sin necesidad de desmontar directorios. Echa un vistazo a la respuesta de Marcel G a continuación que explica cómo. - mhsekhavat
Debe mostrar los comandos CLI para hacer esto en su respuesta - Jonathan
¡VERIFIQUE incluso si piensa que no tiene sentido para usted! - Chris


Simplemente tropecé en esta página al intentar localizar un problema en un servidor local.

En mi caso el df -h y du -sh no coinciden en aproximadamente el 50% del tamaño del disco duro.

Esto se debió a que apache (httpd) tenía archivos de registro grandes en la memoria que se había eliminado del disco.

Esto fue rastreado corriendo lsof | grep "/var" | grep deleted dónde /var Era la partición que necesitaba para limpiar.

La salida mostró líneas como esta:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

La situación se resolvió entonces reiniciando apache (service httpd restart), y eliminó 2 GB de espacio en disco, permitiendo que se borren los bloqueos de los archivos eliminados.


71
2018-03-12 11:10



Para mí, los bloqueos no se liberaron incluso después de que detuve el programa (¿zombies?). Tuve que kill -9 'pid' para liberar las cerraduras. por ejemplo: para su httpd hubiera sido kill -9 32617. - Micka
Nota menor: puede que tenga que correr lsof como sudo o no se mostrarán todos los descriptores de archivos abiertos - ChrisWue
Me topé con esto con H2, que estaba agregando varios conciertos a un archivo de registro todos los días. En lugar de reiniciar H2 (lento), utilicé sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd). - Desty
En mi caso, incluso al reiniciar. httpd El espacio no se libera. Cuando corri /etc/init.d/rsyslog restart funcionó: D - Thanh Nguyen Van
Puedes saltarte los greps y solo hacer lsof -a +L1 /var, dónde -a significa Y todas las condiciones (por defecto es OR), +L1 significa enumerar solo archivos con un número de enlaces inferior a 1 (es decir, archivos eliminados con descriptores de archivos abiertos), y /var restricciones a los archivos bajo ese punto de montaje - kbolino


Estoy de acuerdo con la respuesta de OldTroll como la causa más probable de su espacio "perdido".

En Linux, puede volver a montar fácilmente la partición raíz completa (o cualquier otra partición) en otro lugar de su sistema de archivos, digamos / mnt, por ejemplo, simplemente emita un

mount -o bind / /mnt

entonces puedes hacer un

du -h /mnt

Y ver qué consume tu espacio.

Ps: perdón por agregar una nueva respuesta y no un comentario, pero necesitaba algún formato para que esta publicación sea legible.


40
2018-05-30 13:54



Muchas gracias por este consejo. ¡Me permitió encontrar y eliminar mis archivos grandes "ocultos" sin tiempo de inactividad! - choover
Gracias, esto demostró que la ventana acoplable estaba llenando mi disco duro con diferencias en /var/lib/docker/aufs/diff/ - naught101


Mira qué df -i dice. Es posible que se haya quedado sin inodos, lo que puede suceder si hay una gran cantidad de archivos pequeños en ese sistema de archivos, que utiliza todos los inodos disponibles sin consumir todo el espacio disponible.


23
2018-05-30 14:10



El tamaño de un archivo y la cantidad de espacio que ocupa en un sistema de archivos son dos cosas separadas. Cuanto más pequeños tienden a ser los archivos, mayor es la discrepancia entre ellos. Si escribe un script que resume los tamaños de los archivos y lo compara con el du -s Del mismo subárbol, obtendrás una buena idea si ese es el caso aquí. - Marcin


En mi caso esto tuvo que ver con grandes archivos borrados. Fue bastante doloroso resolverlo antes de encontrar esta página, que me puso en el camino correcto.

Finalmente resolví el problema usando lsof | grep deleted, que me mostró qué programa contenía dos archivos de registro muy grandes (con un total de 5 GB de mi partición raíz de 8 GB disponible).


15
2017-11-14 18:15



Esta respuesta me hace preguntarme por qué almacena los archivos de registro en la partición raíz, especialmente uno tan pequeño ... pero supongo que para cada uno de ellos es suyo. - α CVn
Tuve un problema similar, reinicié todas las aplicaciones que usaban el archivo eliminado, supongo que había un proceso zombie que aún se aferraba a un archivo eliminado grande - user1965449
Este fue nuestro caso, una aplicación de Linux de procesamiento de registros conocida como filebeat mantuvo los archivos abiertos. - Pykler


Los archivos abiertos por un programa en realidad no desaparecen (dejan de consumir espacio en el disco) cuando los elimina, desaparecen cuando el programa los cierra. Un programa puede tener un archivo temporal enorme que usted (y du) no puede ver. Si se trata de un programa zombie, es posible que necesites reiniciar para borrar esos archivos.


5
2018-05-30 12:51



OP dijo que había reiniciado el sistema y el problema persistía. - OldTroll
Tuve zombies que no liberarían los bloqueos de los archivos, kill -9 'pid' Para liberar los bloqueos y recuperar el espacio en disco. - Micka


¡Este es el método más fácil que he encontrado hasta la fecha para encontrar archivos grandes!

Aquí hay un ejemplo si su montaje raíz está lleno / (montaje / raíz) Ejemplo:

discos compactos / (asi estas en la raiz)

ls | xargs du -hs

Ejemplo de salida:

 Contenedor de 9.4M
 63M de arranque
 4.0K cgroup
 680K dev
 31M etc
 6.3G a casa
 313M lib
 32M lib64
 16K perdido + encontrado
 61G medios
 4.0K mnt
 113M opt
 du: no puedo acceder a `proc / 6102 / task / 6102 / fd / 4 ': no ​​existe tal archivo o directorio
 0 proc
 Raíz de 19M
 Carrera de 840K
 19M sbin
 4.0K selinux
 Srv 4.0K
 Tienda 25G
 26M tmp

entonces notarías que almacenar es grande hacer un tienda de cds

y correr de nuevo

ls | xargs du -hs

Ejemplo de salida:
 Copia de seguridad de 109M
 FNB 358M
 Iso 4.0G
 8.0k ks
 16K perdido + encontrado
 Raíz 47M
 11M scripts
 79M tmp
 21G vms

En este caso, el directorio vms es el espacio hog.


4
2018-06-26 13:05



¿Por qué no usar herramientas más simples como baobab? (ver marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
Hm ls + xargs parece una exageración, du -sh /* funciona bien por sí mismo - ChrisWue
Si no sabes sobre ncdu ... me lo agradecerás más tarde: dev.yorhel.nl/ncdu - Troy Folger