df dice que el disco está lleno, pero no lo está

En un servidor virtualizado que ejecuta Ubuntu 10.04, df informa lo siguiente:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.4G  7.0G     0 100% /
none                  498M  160K  498M   1% /dev
none                  500M     0  500M   0% /dev/shm
none                  500M   92K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  500M     0  500M   0% /lib/init/rw
/dev/sda3             917G  305G  566G  36% /home

Esto me desconcierta por dos razones: 1.) df dice que / dev / sda1, montado en /, tiene una capacidad de 7,4 gigabytes, de los cuales solo 7,0 gigabytes están en uso, pero informa que está 100% lleno; y 2.) Puedo crear archivos en / por lo que claramente queda espacio.

Posiblemente relevante es que el directorio / www es un enlace simbólico a / home / www, que está en una partición diferente (/ dev / sda3, montado en / home).

¿Alguien puede ofrecer sugerencias sobre lo que podría estar pasando aquí? El servidor parece estar funcionando sin problemas, pero quiero asegurarme de que no haya un problema con la tabla de particiones, los sistemas de archivos u otra cosa que pueda provocar una implosión (o explosión) más adelante.

Es posible que un proceso haya abierto un archivo grande que desde entonces se ha eliminado. Tendrás que matar ese proceso para liberar el espacio. Puede identificar el proceso utilizando lsof. En Linux, los archivos eliminados pero abiertos son conocidos por lsof y marcados como (eliminados) en la salida de lsof.

Puedes verificar esto con sudo lsof +L1

El 5% (por defecto) del sistema de archivos está reservado para los casos en que el sistema de archivos se llena para evitar problemas graves. Tu sistema de archivos está lleno. No ocurre nada catastrófico debido al búfer de 5%: la raíz puede usar ese búfer de seguridad y, en su configuración, los usuarios no root no tienen ninguna razón para escribir en ese sistema de archivos.

Si tiene demonios que se ejecutan como usuarios no root pero que necesitan administrar archivos en ese sistema de archivos, las cosas se romperán. Un demonio común es named. Otro es ntpd.

Puede que te quedes sin inodos. Verifique el uso del inodo con este comando:

df -i

La mayoría de los sistemas de archivos de Linux reservan un 5% de espacio para usar solo el usuario raíz.

Puedes ver esto con, por ejemplo,

dumpe2fs /dev/sda1 | grep -i reserved

Puede cambiar la cantidad reservada usando:

tune2fs -m 0 /dev/sda1

En la mayoría de los casos, el servidor parecerá seguir funcionando bien, suponiendo que todos los procesos se ejecuten como 'root'.

Tuve este problema y estaba desconcertado por el hecho de que eliminar varios archivos grandes no mejoró la situación (no sabía sobre el búfer del 5%) de todos modos, siguiendo algunas pistas aquí

Desde la raíz recorrió los directorios más grandes revelados haciendo repetidamente: -

du -sh */ 

hasta que encontré un directorio para los archivos de registro del servidor web que tenía algunos registros absolutamente masivos

que trunqué con

:>lighttpd.error.log

De repente, df -h se había reducido al 48%.

Además de las causas ya sugeridas, en algunos casos también podría ser el siguiente:

• se monta un disco diferente "sobre" la carpeta existente que está llena de datos
• du calculará el tamaño gastado del disco montado y df mostrará realmente gastado
• solución: (cuando sea posible) desmonte todos los discos no root y verifique el tamaño du -md 1nuevamente. Solucione la situación moviendo la carpeta oculta a otro lugar o monte en un lugar diferente.

df -hestá redondeando los valores. Incluso los porcentajes son redondeados. Omita -hy verá diferencias más finas.

Oh. Y ext3 y sus derivados reservan un porcentaje (por defecto del 5%) para el sistema de archivos para exactamente esta problemática constelación. Si su sistema de archivos raíz estuviera realmente lleno (0 bytes restantes) no puede arrancar el sistema. Entonces la porción reservada evita esto.

Hice una gran actualización de varias bibliotecas y había muchas bibliotecas y archivos temporales innecesarios, así que libero espacio en la carpeta "/" usando:

apt-get install -f
sudo apt-get clean

Y vacia tu basura

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

Si su partición es btrfs, puede haber un subvolumen que tome espacio. Un sistema de archivos btrfs puede tener muchos subvolúmenes, de los cuales solo uno está montado. Puede usar btrfs subvolume list <dir>para enumerar todos los subvolúmenes y btrfs subvolume delete <dir>/<subvolume>para eliminar uno. Asegúrese de no eliminar el que está montado de forma predeterminada.