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

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.

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

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.

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.

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.

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

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.

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

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

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.

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

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.

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.

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

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

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.

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.

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