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


110

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

Sin embargo, si ejecuto a du -h -x /, dume dice que solo se usan 12G (lo uso -xdebido a algunas monturas 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 por un fsck que no tenía errores. ¿Debo correr badblocks? lsofme muestra que no hay archivos eliminados abiertos, lost+foundestá vacío y no hay una declaración obvia de advertencia / error / falla en el archivo de mensajes.

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


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

Respuestas:


93

Verifique los archivos ubicados debajo de los puntos de montaje. Con frecuencia, si monta un directorio (digamos un sambafs) en un sistema de archivos que ya tenía un archivo o directorios, 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 volcado de archivos en directorios que no podía ver, excepto en modo de usuario único (debido a que otros sistemas de directorios se montan encima de ellos).


3
Puede encontrar estos archivos ocultos sin necesidad de desmontar directorios. Eche un vistazo a la respuesta de Marcel G a continuación que explica cómo.
mhsekhavat

Debería mostrar los comandos de CLI para hacer esto en su respuesta
Jonathan

1
¡COMPRUEBE incluso si cree que no tiene sentido para usted!
Chris

1
Nota: esta respuesta habla de archivos ubicados debajo de los puntos de montaje (es decir, ocultos en el sistema de archivos original), no dentro de los puntos de montaje. (No seas idiota como yo.)
mwfearnley

92

Acabo de tropezar con esta página al intentar localizar un problema en un servidor local.

En mi caso, el df -hy du -shno coinciden en un 50% del tamaño del disco duro.

Esto fue causado por apache (httpd) que mantenía grandes archivos de registro en la memoria que habían sido eliminados del disco.

Esto se rastreó ejecutando lsof | grep "/var" | grep deleteddónde /varestaba la partición que necesitaba 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ó reiniciando apache ( service httpd restart) y eliminó 2 gb de espacio en disco, permitiendo que se borren los bloqueos de los archivos eliminados.


Para mí, las cerraduras no se liberaron incluso después de que detuve el programa (¿zombies?). Tuve kill -9 'pid'que liberar las cerraduras. por ejemplo: para su httpd lo hubiera sido kill -9 32617.
Micka

66
Nota menor: Usted puede tener que funcionar lsofcomo sudoo no todos los descriptores de archivos abiertos se mostrará
ChrisWue

Me encontré con esto con H2, que agregaba varios conciertos a un archivo de registro todos los días. En lugar de reiniciar H2 (lento), solía sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd).
Desty

En mi caso, incluso cuando el httpdespacio de reinicio no se libera. Cuando corrí /etc/init.d/rsyslog restartfuncionó: D
Thanh Nguyen Van

2
Puede omitir los greps y simplemente hacer lsof -a +L1 /var, donde -asignifica Y todas las condiciones (el valor predeterminado es OR), +L1significa enumerar solo los archivos con un recuento de enlaces inferior a 1 (es decir, archivos eliminados con descriptores de archivo abiertos) y /varrestringir a los archivos bajo ese punto de montaje
kbolino

52

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 toda la partición raíz (o cualquier otra partición) en otro lugar de su sistema de archivos, por ejemplo, / mnt, simplemente emita un

mount -o bind / /mnt

entonces puedes hacer un

du -h /mnt

y ver qué usa tu espacio.

PD: lo siento por agregar una nueva respuesta y no un comentario, pero necesitaba un poco de formato para que esta publicación sea legible.


3
Muchas gracias por este consejo. ¡Me permitió encontrar y eliminar mis grandes archivos "ocultos" sin tiempo de inactividad!
Choover

Gracias, esto demostró que Docker estaba llenando mi disco duro con diffs en/var/lib/docker/aufs/diff/
naught101

mount -o bind / /mntme dio una información adicional que estaba buscando. ¡Gracias!
Slavik Meltser

25

Mira lo que df -idice. Puede ser que se haya quedado sin inodos, lo que podría 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.


1
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 son los archivos, mayor es la discrepancia entre ellos. Si escribe un script que resume el tamaño de los archivos y lo compara con du -sel mismo subárbol, obtendrá una buena idea si ese es el caso aquí.
Marcin

24

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

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


1
Esta respuesta me pregunto por qué va a almacenar los archivos de registro en la partición raíz, especialmente uno tan pequeño ... pero a cada uno su propio, supongo ...
una CVn

Tuve un problema similar, reinicié todas las aplicaciones que usaban el archivo eliminado, supongo que todavía había un proceso zombie
aferrado

Este fue el caso para nosotros, una aplicación de Linux de procesamiento de registros conocida como filebeat mantuvo los archivos abiertos.
Pykler

@Pykler Para nosotros también fue filebeat. ¡Gracias por el consejo!
Martijn Heemels

7

Los archivos abiertos por un programa en realidad no desaparecen (dejan de consumir espacio en 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 es un programa zombie, es posible que deba reiniciar para borrar esos archivos.


OP dijo que había reiniciado el sistema y el problema persistió.
OldTroll

Tenía zombies que no soltaban las cerraduras de los archivos, yo kill -9 'pid'para liberar las cerraduras y recuperar el espacio en disco.
Micka

5

Pruebe esto para ver si un proceso inactivo / bloqueado está bloqueado mientras sigue escribiendo en el disco: lsof | grep "/ mnt"

Luego intente eliminar cualquier PID que esté atascado (especialmente busque líneas que terminen en "(eliminado"))


¡Gracias! Pude encontrar que el proceso del servidor SFTP contenía el archivo eliminado
lyomi

4

¡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:

cd / (para que estés en la raíz)

ls | xargs du -hs

Salida de ejemplo:

 9,4 millones de contenedores
 63M de arranque
 4.0K cgroup
 680K dev
 31 millones, etc.
 6.3G en casa
 313M lib
 32M lib64
 16K perdido + encontrado
 61G media
 4.0K mnt
 113M opta
 du: no puede acceder a `proc / 6102 / task / 6102 / fd / 4 ': No existe tal archivo o directorio
 0 proc
 Raíz 19M
 840K de carrera
 19M sbin
 4.0K selinux
 4.0K srv
 Tienda 25G
 26M tmp

entonces notarías que la tienda es grande, haz un cd / store

y corre de nuevo

ls | xargs du -hs

Salida de ejemplo: 
 109M de respaldo
 358M fnb
 Iso 4.0G
 8.0K ks
 16K perdido + encontrado
 Raíz 47M
 11 millones de guiones
 79M tmp
 21G vms

en este caso el directorio vms es el espacio hog.


1
¿Por qué no usar herramientas más simples como baobab? (ver marzocca.net/linux/baobab/baobab-getting-started.html )
Yvan,

2
Hm ls+ xargsparece excesivo, du -sh /*funciona bien solo
ChrisWue

1
si no sabe acerca de ncdu ... me lo agradecerá más tarde: dev.yorhel.nl/ncdu
Troy Folger

3

Para mí, necesitaba ejecutar sudo duya que había una gran cantidad de archivos acoplables debajo de los /var/lib/dockercuales un usuario que no es sudo no tiene permiso para leer.


Este fue mi problema. Olvidé que cambié los sistemas de almacenamiento en la ventana acoplable y los viejos volúmenes todavía estaban dando vueltas.
Richard Nienaber

1

Una posibilidad más a tener en cuenta: está casi garantizado que verá una gran discrepancia si está usando Docker y ejecuta df / du dentro de un contenedor que está utilizando montajes de volumen. En el caso de un directorio montado en un volumen en el host docker, df informará los totales de df del HOST. Esto es obvio si lo piensa, pero cuando reciba un informe de un "contenedor fuera de control que llena el disco", asegúrese de verificar el consumo del espacio de archivos del contenedor con algo como esto du -hs <dir>.


1

Así que también tuve este problema en Centos 7 y encontré una solución después de probar un montón de cosas como bleachbit y limpieza / usr y / var a pesar de que solo mostraban alrededor de 7G cada una. Todavía mostraba 50G de 50G utilizados en la partición raíz, pero solo mostraba 9G de uso de archivos. Ejecuté un cd ubuntu en vivo y desmonté la partición 50G ofensiva, abrí la terminal y ejecuté xfs_check y xfs_repair en la partición. Luego volví a montar la partición y mi directorio perdido + encontrado se expandió a 40G. Clasifiqué el perdido + encontrado por tamaño y encontré un archivo de registro de texto de 38G para steam que eventualmente solo repitió un error de mp3. Eliminé el archivo grande y ahora tengo espacio y el uso de mis discos está de acuerdo con el tamaño de mi partición raíz. Todavía me gustaría saber cómo hacer que el registro de vapor no vuelva a crecer tanto.


¿Te pasó esto en el trabajo? serverfault.com/help/on-topic
pollitos

No solo en la computadora de mi casa.
Justin Chadwick

3
xfs_fsrsolucionó este problema para nosotros
Druska

0

si el disco montado es una carpeta compartida en una máquina con Windows, entonces parece que df mostrará el tamaño y el uso del disco de todo el disco de Windows, pero du mostrará solo la parte del disco a la que tiene acceso también. (y está montado). en este caso, el problema debe solucionarse en la máquina con Windows.


0

Algo similar nos sucedió en producción, el uso del disco fue del 98%. Hizo la siguiente investigación:

a) df -ipara verificar el uso del inodo, el uso del inodo fue del 6%, por lo que no hay archivos mucho más pequeños

b) Montaje rooty comprobación de archivos ocultos. No se pudieron presentar archivos adicionales . duLos resultados fueron los mismos que antes del montaje.

c) Finalmente, se verificaron los nginxregistros. Se configuró para escribir en el disco, pero un desarrollador eliminó el archivo de registro directamente, lo nginxque provocó que todos los registros se mantuvieran en la memoria. Como el archivo /var/log/nginx/access.logse eliminó del disco, rmno se pudo ver, dupero se accedió al archivo nginxy, por lo tanto, todavía se mantuvo abierto


0

Tuve el mismo problema que se menciona en este tema, pero en un VPS. Así que probé todo lo que se describe en este tema pero sin éxito. La solución fue un contacto de soporte con nuestro proveedor de VPS que realizó un nuevo cálculo de cuotas y corrigió la diferencia de espacio de df -hy du-sh /.


0

Hoy me encontré con este problema en un cuadro de FreeBSD. El problema era que era un artefacto de vi(no vim, no estoy seguro si vimcrearía este problema). El archivo consumía espacio pero no se había escrito completamente en el disco.

Puede verificar eso con:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Esto examina todos los archivos abiertos y los ordena (numéricamente -n) en la octava columna (clave, -k8), que muestra los últimos diez elementos.

En mi caso, la entrada final (más grande) se veía así:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Esto significaba que el proceso (PID) 12345 consumía 1.46G (la octava columna dividida por 1024³) de disco a pesar de la falta de dunotarlo. vies horrible al ver archivos extremadamente grandes; incluso 100 MB es grande para ello. 1.5G (o por grande que sea ese archivo) es ridículo.

La solución era sudo kill -HUP 12345(si eso no funcionara, sudo kill 12345y si eso también falla, lo temido kill -9entraría en juego).

Evite los editores de texto en archivos grandes. Ejemplos de soluciones para el desnatado rápido:

Suponiendo longitudes de línea razonables:

  • { head -n1000 big.log; tail -n1000 big.log } |vim -R -
  • wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Asumiendo líneas irrazonablemente grandes:

  • { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Estos se usan vim -Ren lugar de viewporque vimcasi siempre es mejor ... cuando está instalado. Siéntase libre de colocarlos en su lugar viewo en su vi -Rlugar.

Si va a abrir un archivo tan grande para editar en realidad, considerar sedo awko algún otro enfoque programático.


0

compruebe si su servidor tiene instalado el agente ossec. O algún proceso está utilizando los archivos de registro eliminados. En mi hace un tiempo era agente ossec.


1
OP mencionó que la máquina se reinició, por lo que no deberían quedar archivos eliminados.
RalfFriedl

-3

compruebe el / lost + found, tenía un sistema (centos 7) y algunos de los archivos en / lost + found ocuparon todo el espacio.


¿Cómo explicaría esto la diferencia en el uso de disco informado como se describe en la pregunta ?
roaima
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.