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

eliminação de ficheiros mas o espaço em disco ainda está cheio

Lidando com a antiga caixa CentOS 5.6, sem configuração lvm, o meu sistema de ficheiros raiz / está cheio, limpei muitos ficheiros de registo antigos e ficheiros de aplicação de que não preciso, que tinham mais de 2 -5GB de tamanho, no entanto o meu sistema ainda reporta que o disco está cheio.

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

Qualquer ideia sobre o que devo tentar fazer a seguir? infelizmente reiniciar a caixa não é uma opção neste momento.

Respostas (9)

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

Duas coisas podem estar a acontecer aqui.

Primeiro , o seu sistema de ficheiros reservou algum espaço em que apenas root pode escrever, para que o processo crítico do sistema não caia quando os utilizadores normais ficarem sem espaço em disco. É por isso que vê 124G de 130G utilizado, mas zero disponível. Talvez os ficheiros que eliminou tenham reduzido a utilização até este ponto, mas não abaixo do limiar para utilizadores normais.

Se esta for a sua situação e estiver desesperado, talvez consiga alterar a quantidade de espaço reservado para root. Para o reduzir para 1% (o padrão é 5%), o seu comando seria

# tune2fs -m 1 /dev/sda3

Segundo , o sistema operativo não libertará espaço em disco para ficheiros apagados que ainda estejam abertos. Se tiver apagado (digamos) um dos ficheiros de registo do Apache, terá de reiniciar o Apache de modo a libertar o espaço.

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

Se eliminar um ficheiro que está a ser utilizado por um processo, já não pode ver o ficheiro por ls. O processo ainda está a escrever para esse ficheiro até parar o processo.

Para ver os ficheiros apagados, basta executar lsof|grep delete&.

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

2 outras formas de obter o disco está cheio edição:

1) coberto sob um ponto de montagem: linux mostrará um disco completo com ficheiros “escondidos” sob um ponto de montagem. Se tiver dados escritos na unidade e montar outro sistema de ficheiros sobre ela, o linux regista correctamente a utilização do disco mesmo que não consiga ver os ficheiros sob o ponto de montagem. Se tiver nfs montadas, tente montá-las e procurar ver se algo foi escrito acidentalmente nesses directórios antes da montagem.

2) ** ficheiros corrompidos:** Vejo isto ocasionalmente no windows para transferência de ficheiros linux via SMB. Um ficheiro não fecha o descritor de ficheiro e acaba com um ficheiro de lixo de 4GB.

Isto pode ser mais aborrecido de corrigir, porque é necessário encontrar a subdirectoria em que o ficheiro está, mas é fácil de corrigir porque o ficheiro em si é facilmente removível. Utilizo o comando du e faço uma listagem dos subdirectórios raiz para descobrir onde o espaço do ficheiro está a ser utilizado.

cd /
du -sh ./*

O número de directórios de nível superior é normalmente limitado, por isso, ponho a bandeira humana legível* -h para ver que subdirectório é o porco do espaço.

Depois cd na criança problemática e repito o processo para todos os itens nela contidos. Para tornar isto fácil de detectar os itens grandes, mudamos ligeiramente o du e acoplamo-lo com uma espécie.

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

que produz um byte de saída do menor ao maior tamanho para todos os ficheiros e directórios

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

Uma vez detectado o ficheiro sobredimensionado, geralmente pode simplesmente apagá-lo.

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

Poderá descobrir que ficheiros estão abertos com lsof. Pode produzir muita produção, por isso limitei-me, no exemplo abaixo, a linhas que terminam com 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

Se alguns ficheiros forem apagados mas ainda assim utilizados por algum processo, então o seu espaço não será libertado. Neste caso, ou reinicia um processo que esteja a utilizar o ficheiro ou anula o ficheiro. É sempre boa prática anular tais ficheiros em vez de os apagar. Para encontrar ficheiros apagados mas que ainda estão em uso por algum processo

#lsof +L1

dará id de processo e descritor de ficheiro. Para anular ficheiro apagado por descritor de ficheiro

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

Na maioria dos casos, se eliminarmos quaisquer ficheiros de registo, deixa de ver o ficheiro por ls. O processo continua a escrever para esse ficheiro até que o processo seja interrompido.

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

Digite o comando

#lsof +L1

Que mostrará a lista de ficheiros que possuem memória com citação eliminada.

Note o pid ( Process id ) do ficheiro

Mata o processo

#kill <pid>

A memória será libertada pelo processo

Verifique pelo comando

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

Problema real observado na natureza:

Certifique-se de que está a apagar os ficheiros reais e não os symlinks para os ficheiros. Este pode ser especialmente o caso dos ficheiros de registo.

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

Além do que foi explicado, a questão poderia ser que existe um outro ponto de montagem do directório de ficheiros eliminado noutro dispositivo de disco anexado no mesmo servidor. Verificar as montagens actuais e as entradas fstab.