excluindo arquivos, mas o espaço em disco ainda está cheio

Question

Lidando com a antiga caixa do CentOS 5.6, sem configuração lvm, meu sistema de arquivos raiz / está cheio, eu limpei muitos arquivos de log antigos e arquivos de aplicativos que eu não preciso, que tinham mais de 2 -5 GB de tamanho no entanto, meu sistema ainda relata 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)

Alguma ideia do que devo fazer em seguida? infelizmente, reiniciar a caixa não é uma opção no momento.

    

Answer 1

Duas coisas podem estar acontecendo aqui.

Primeiro , seu sistema de arquivos reservou algum espaço para o qual apenas root pode gravar, para que o processo crítico do sistema não caia quando os usuários normais ficarem sem espaço em disco. É por isso que você vê 124G de 130G usado, mas zero disponível. Talvez os arquivos que você excluiu tenham baixado a utilização até esse ponto, mas não abaixo do limite para usuários normais.

Se esta é a sua situação e você está desesperado, você pode alterar a quantidade de espaço reservada para root . Para reduzi-lo a 1% (o padrão é 5%), seu comando seria

# tune2fs -m 1 /dev/sda3

Segundo , o sistema operacional não libera espaço em disco para arquivos excluídos que ainda estão abertos. Se você tiver excluído (digamos) um dos arquivos de log do Apache, será necessário reiniciar o Apache para liberar espaço.

    

Answer 2

Se você excluir um arquivo que está sendo usado por um processo, não poderá mais visualizá-lo por ls . O processo ainda está sendo gravado nesse arquivo até que você pare o processo.

Para ver esses arquivos excluídos, basta executar lsof|grep delete

    

Answer 3

2 outras formas de obter o disco está cheio :

1) oculto em um ponto de montagem: o linux mostrará um disco inteiro com arquivos "ocultos" em um ponto de montagem. Se você tiver dados gravados na unidade e montar outro sistema de arquivos sobre ele, o linux anotará corretamente o uso do disco mesmo que você não consiga ver os arquivos sob o ponto de montagem. Se você tiver montagens nfs, tente enumerá-las e verificar se alguma coisa foi gravada acidentalmente nesses diretórios antes da montagem.

2) arquivos corrompidos: Eu vejo isso ocasionalmente no Windows para transferência de arquivos via Linux via SMB. Um arquivo não consegue fechar o descritor de arquivo e você acaba com um arquivo de lixo de 4GB.

Isso pode ser mais tedioso para corrigir, porque você precisa encontrar o subdiretório em que o arquivo está, mas é fácil de corrigir porque o arquivo em si é facilmente removível. Eu uso o comando du e faço uma listagem dos subdiretórios raiz para descobrir onde o espaço no arquivo está sendo usado.

cd /
du -sh ./* 

O número de diretórios de nível superior é geralmente limitado, por isso, defino a sinalização legível por humanos -h para ver qual subdiretório é o sujeira de espaço.

Então, você entra no filho problemático e repete o processo para todos os itens nele. Para facilitar a identificação dos itens grandes, mudamos o tamanho do objeto e o associamos a uma espécie.

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

que produz uma menor para a maior saída por tamanho de byte para todos os arquivos e diretórios

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

Depois de identificar o arquivo superdimensionado, normalmente é possível excluí-lo.

    

Answer 4

Você pode descobrir quais arquivos estão abertos com lsof. Pode produzir muita saída, por isso limitei no exemplo abaixo às 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
...

    

Answer 5

Além do que foi explicado, o problema pode ser que haja outro ponto de montagem do diretório de arquivos excluídos em outro dispositivo de disco conectado no mesmo servidor. Verifique as montagens atuais e as entradas do fstab.

    

Answer 6

Problema real observado na natureza:

Verifique se você está excluindo os arquivos reais e não os links simbólicos para os arquivos. Este pode ser o caso de arquivos de log especialmente.

    

Answer 7

Se alguns arquivos forem excluídos, mas ainda usados por algum processo, o espaço não será liberado. Nesse caso, reinicie um processo que esteja usando o arquivo ou anule o arquivo. É sempre uma boa prática anular esses arquivos em vez de excluí-los. Para encontrar arquivos apagados, mas ainda estão em uso por algum processo

#lsof +L1

dará id do processo e descritor de arquivo. Para null arquivo apagado pelo descritor de arquivo

#echo "" > /proc/$pid/fd/$fd 

    

Answer 8

Digite o comando

#lsof +L1

O que mostrará a lista de arquivos que armazenam memória com a cotação excluída.

Observe o pid (id do processo) do arquivo

Mate o processo

#kill <pid>

A memória será liberada pelo processo

Verifique por comando

#df -h