2014-04-07 13:42:39 +0000 2014-04-07 13:42:39 +0000
26
26

borrando archivos pero el espacio en disco sigue lleno

Tratando con la vieja caja de CentOS 5.6, sin configuración lvm, mi sistema de archivos raíz / está lleno, he limpiado muchos archivos de registro antiguos y archivos de aplicaciones que no necesito, que era más de 2 -5GB de tamaño, sin embargo mi sistema todavía informa que el disco está lleno.

[root@tornms1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 130G 124G 0 100% /
/dev/sdb1 264G 188M 250G 1% /data
/dev/sda1 99M 24M 71M 26% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm

[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

¿Alguna idea de lo que debería intentar hacer a continuación? desafortunadamente reiniciar la caja no es una opción en este momento.

Respuestas (9)

38
38
38
2014-04-07 14:02:13 +0000

Aquí pueden estar ocurriendo dos cosas.

Primero , su sistema de archivos ha reservado algún espacio en el que sólo root puede escribir, para que los procesos críticos del sistema no se caigan cuando los usuarios normales se queden sin espacio en el disco. Por eso ves 124G de 130G utilizados, pero cero disponibles. Tal vez los archivos que borraste hicieron que la utilización bajara a este punto, pero no por debajo del umbral para los usuarios normales.

Si esta es tu situación y estás desesperado, puedes modificar la cantidad de espacio reservado para root. Para reducirlo al 1% (el valor por defecto es el 5%), tu comando sería

# tune2fs -m 1 /dev/sda3

Segundo , el sistema operativo no liberará espacio en disco para los archivos borrados que aún estén abiertos. Si ha borrado (por ejemplo) uno de los archivos de registro de Apache, tendrá que reiniciar Apache para liberar el espacio.

18
18
18
2015-09-24 09:32:08 +0000

Si elimina un archivo que está siendo utilizado por un proceso, ya no podrá ver el archivo por ls. El proceso sigue escribiendo en ese archivo hasta que usted detenga el proceso.

Para ver esos archivos borrados, simplemente ejecutelsof|grep delete

10
10
10
2014-04-07 21:03:43 +0000

Otras 2 formas de obtener el problema de disco lleno:

1) ocultos bajo un punto de montaje: linux mostrará un disco lleno con archivos “ocultos” bajo un punto de montaje. Si tienes datos escritos en el disco y montas otro sistema de archivos sobre él, linux anota correctamente el uso del disco aunque no puedas ver los archivos bajo el punto de montaje. Si tiene montajes nfs, intente desmontarlos y ver si se escribió algo accidentalmente en esos directorios antes del montaje.

2) Archivos corruptos: Veo esto ocasionalmente en la transferencia de archivos de windows a linux vía SMB. Un archivo falla al cerrar el descriptor de archivo y terminas con un archivo de 4GB de basura.

Esto puede ser más tedioso de arreglar, porque necesitas encontrar el subdirectorio en el que está el archivo, pero es fácil de arreglar porque el archivo en sí es fácilmente removible. Yo uso el comando du y hago un listado de los subdirectorios de la raíz para averiguar dónde se está utilizando el espacio del archivo.

cd /
du -sh ./*

El número de directorios de nivel superior suele ser limitado, así que pongo la bandera human readable -h para ver qué subdirectorio es el que acapara el espacio.

A continuación, se accede al subdirectorio problemático y se repite el proceso para todos los elementos que contiene. Para facilitar la detección de los elementos grandes, cambiamos ligeramente el du y lo combinamos con una ordenación.

cd /<suspiciously large dir>
du -s ./* | sort -n

que produce una salida de menor a mayor tamaño por bytes para todos los archivos y directorios

4 ./bin 
462220 ./Documents
578899 ./Downloads
5788998769 ./Grocery List

Una vez que se detecta el archivo de gran tamaño, normalmente se puede eliminar.

4
4
4
2014-04-07 14:27:52 +0000

Puedes averiguar qué archivos están abiertos con lsof. Puede producir una gran cantidad de salida, por lo que me limité en el ejemplo de abajo a las líneas que terminan con log:

# lsof | grep log$
rsyslogd 2109 syslog 0u unix 0xffff88022fa230c0 0t0 8894 /dev/log
rsyslogd 2109 syslog 1w REG 252,6 62393 26 /var/log/syslog
rsyslogd 2109 syslog 2w REG 252,6 113725 122 /var/log/auth.log
rsyslogd 2109 syslog 3u unix 0xffff88022fa23740 0t0 8921 /var/spool/postfix/dev/log
rsyslogd 2109 syslog 5w REG 252,6 65624 106 /var/log/mail.log
/usr/sbin 2129 root 2w REG 252,6 93602 38 /var/log/munin/munin-node.log
/usr/sbin 2129 root 4w REG 252,6 93602 38 /var/log/munin/munin-node.log
...
1
1
1
2017-06-08 10:02:04 +0000

Si algunos archivos se eliminan pero siguen siendo utilizados por algún proceso, su espacio no se liberará. En este caso, puede reiniciar el proceso que está utilizando el archivo o anularlo. Siempre es una buena práctica anular tales archivos en lugar de borrarlos. Para encontrar archivos borrados pero que todavía están en uso por algún proceso

#lsof +L1

dará el id del proceso y el descriptor del archivo. Para anular un archivo borrado por el descriptor de archivo

#echo "" > /proc/$pid/fd/$fd
1
1
1
2020-02-27 01:18:39 +0000

En la mayoría de los casos si borramos algún archivo de registro ya no se ve el archivo por ls. El proceso sigue escribiendo en ese archivo hasta que se detenga el proceso.

1
1
1
2017-10-31 13:45:06 +0000

Escriba el comando

#lsof +L1

El cual mostrará la lista de archivos que mantienen la memoria con cita eliminada.

Anote el pid ( Process id ) del archivo

Mate el proceso

#kill <pid>

La memoria será liberada por el proceso

Compruébelo con el comando

#df -h
0
0
0
2016-06-02 09:58:41 +0000

Problema real observado en la naturaleza:

Asegúrese de que está borrando los archivos reales y no los enlaces simbólicos a los archivos. Este puede ser el caso de los archivos de registro especialmente.

0
0
0
2016-01-23 08:00:36 +0000

Además de lo explicado, el problema puede ser que haya otro punto de montaje del directorio de archivos eliminado en otro dispositivo de disco conectado en el mismo servidor. Compruebe los montajes actuales y las entradas fstab.