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

Lidando com a antiga caixa do CentOS 5.6, sem configuração de lvm, meu sistema de arquivos raiz / está cheio, limpei muitos arquivos de log e arquivos de aplicativos antigos que não preciso, que tinham mais de 2 a 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 idéia do que devo tentar fazer a seguir? infelizmente, a reinicialização da caixa não é uma opção no momento.

Duas coisas podem estar acontecendo aqui.

Primeiro , seu sistema de arquivos reservou algum espaço para o qual somente é rootpossível gravar, para que o processo crítico do sistema não caia quando os usuários normais ficam sem espaço em disco. É por isso que você vê 124G de 130G usados, mas zero disponível. Talvez os arquivos que você excluiu tenham reduzido a utilização a este ponto, mas não abaixo do limite para usuários normais.

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

# tune2fs -m 1 /dev/sda3

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

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

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

2 outras maneiras de obter o disco é a questão completa :

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

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

Isso pode ser mais tedioso de corrigir, porque você precisa encontrar o subdiretório em que o arquivo está, mas é fácil de corrigir, porque o próprio arquivo é facilmente removível. Eu uso o ducomando e faço uma lista 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 o sinalizador legível por humanos-h para ver qual subdiretório é o porco do espaço.

Então você entra no filho problemático e repete o processo para todos os itens nele. Para facilitar a localização dos itens grandes, alteramos um pouco o du e o associamos a uma espécie.

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

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

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

Depois de localizar o arquivo de tamanho grande, geralmente você pode excluí-lo.

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

Se alguns arquivos forem excluídos, mas ainda usados ​​por algum processo, seu 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 excluídos, mas ainda estão em uso por algum processo

#lsof +L1

dará identificação do processo e descritor de arquivo. Para anular arquivo excluído por descritor de arquivo

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

Digite o comando

#lsof +L1

O qual mostrará a lista de arquivos que contêm memória com aspas excluídas.

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

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

Problema real observado na natureza:

Certifique-se de excluir os arquivos reais e não de links simbólicos para os arquivos. Esse pode ser o caso dos arquivos de log, especialmente.