Eu tenho servidores de arquivos que são usados para armazenar arquivos. Os arquivos podem residir por uma semana ou por um ano. Infelizmente, quando eu removo arquivos do servidor, o comando df não reflete o espaço liberado. Então, eventualmente, o servidor é preenchido ( df mostra 99%), e meu script não envia mais arquivos lá, exceto que pode haver algumas dúzias de GB de espaço livre lá.
Eu tenho noatime flag nas partições montadas, se isso faz alguma diferença.
Excluir o nome do arquivo não exclui o arquivo. Algum outro processo está mantendo o arquivo aberto, fazendo com que ele não seja excluído; reinicie ou mate esse processo para liberar o arquivo.
Use
lsof +L1
para descobrir qual processo está usando um arquivo excluído (desvinculado).
como Ignacio menciona, excluir o arquivo não libera o espaço até que você exclua os processos que têm identificadores abertos nesse arquivo.
No entanto, você pode recuperar o espaço sem matar os processos. Tudo o que você precisa fazer é remover os descritores de arquivos.
Primeiro execute lsof | grep deletado para identificar o processo que contém o arquivo
[hudson@opsynxvm0055 log]$ /usr/sbin/lsof |grep deleted
java 8859 hudson 1w REG 253,0 3662503356 7578206 /crucible/data/current/var/log/fisheye.out (deleted)
Em seguida, execute:
cd /proc/PID/fd
então
[hudson@opsynxvm0055 fd]$ ls -l |grep deleted
total 0
l-wx------ 1 hudson devel 64 Feb 7 11:48 1 -> /crucible/data/current/var/log/fisheye.out (deleted)
O "1" será o descritor de arquivo. Agora digite "> FD" para recuperar esse espaço
> 1
Pode ser necessário repetir a operação se houver outros processos que contêm o arquivo.
Uma possibilidade é que o (s) arquivo (s) que você excluiu tenha mais referências no sistema de arquivos. Se você criou hardlinks, vários nomes de arquivos apontarão para os mesmos dados e os dados (o conteúdo real) não serão marcados como livres / utilizáveis até que todas as referências a ele tenham sido removidas. Antes de apagar os arquivos, seja stat (Entrada nomeada Links) ou ls -l (deve ser a segunda coluna).
Se acontecer de os arquivos serem referenciados em outro lugar, eu acho que você terá que ls -i os arquivos para encontrar o inode-number, e então fazer um find com -inum < inode-number & gt ; para encontrar as outras referências a esse arquivo (você provavelmente também desejará usar -mount para permanecer dentro do mesmo sistema de arquivos também).
O arquivo ainda está bloqueado pelo processo de abertura. Para liberar espaço, siga estas etapas:
Execute sudo lsof | grep deleted e veja qual processo está mantendo o arquivo. Exemplo de resultado:
$ sudo lsof | grep deleted
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
cron 1623 root 5u REG 0,21 0 395919638 /tmp/tmpfPagTZ4 (deleted)
Mate o processo usando sudo kill -9 {PID} . Na amostra acima, o PID é 1623.
$ sudo kill -9 1623
Execute df para verificar se o espaço já está liberado. Se ainda estiver cheio, talvez você precise aguardar alguns segundos e verificar novamente.
Se a partição tiver sido configurada para reservar certa parte do espaço em disco apenas para uso da raiz, df não incluirá esse espaço como disponível.
[root@server]# df -h
Filesystem Size Used Avail Use% Mounted on
...
/dev/optvol 625G 607G 0 100% /opt
...
Mesmo depois de o espaço ser recuperado pela exclusão de arquivos / diretórios, o usuário não-root não poderá gravar em uma partição específica.
Você pode verificar facilmente se esse é o seu caso tentando criar um arquivo em um dispositivo como usuário raiz e não raiz.
Além disso, você pode verificar a configuração do sistema de arquivos executando
tune2fs -l <device> | egrep "Block count|Reserved block count
e calculando% real por conta própria.
Para alterar o disco% reservado para uso somente raiz, execute
tune2fs -m <percentage> <device>
As outras respostas estão corretas: se você excluir um arquivo e o espaço não for liberado, geralmente é porque o arquivo ainda é mantido aberto ou há outros links para ele.
Para ajudar na solução de problemas, use uma ferramenta que informa onde o espaço da unidade está sendo gasto: Você pode usar du para obter uma visão geral de onde o espaço está indo. Melhor ainda, use uma ferramenta gráfica como xdiskusage (há muitos como este) para caçar o culpado. xdiskusage e seus amigos permitem que você explore os maiores porcos do espaço para descobrir onde o espaço está indo.
Dessa forma, você encontrará rapidamente arquivos que ainda ocupam espaço por causa de um segundo link físico. Ele também mostrará o espaço ocupado por arquivos excluídos, mas abertos (como (permissão negada), creio eu, já que ele não pode ler o nome do arquivo).
Desde que eu sei que muitos de vocês estão fazendo isso para redhat em /var e gzipping arquivos esperando o FS encolher, mas em vez disso ele cresce, apenas certifique-se de que o syslog seja reiniciado. e
lsof -v file
mostraria isso de qualquer maneira.
Mais uma opção: o disco pode estar cheio devido a um processo que está continuamente criando dados: logs, núcleos e afins. É possível que o espaço esteja sendo liberado, mas seja imediatamente preenchido. Eu realmente vi esse caso. df neste caso simplesmente não fornece a imagem do furo. Use du para saber mais.
Estou usando o EXT2, o FSCK me ajudou nessa situação. Tente shudown -F agora, depois de algumas reinicializações e fscks, vejo metade do espaço usado.
Para verificar quais arquivos apagados ocuparam a memória, digite o comando
$ sudo lsof | grep deleted
Ele mostrará os arquivos excluídos que guardam memória.
Em seguida, mate o processo com pid ou nome
$ sudo kill <pid>
$ df -h
verifique agora que você terá a mesma memória
Se não digitar o comando abaixo para ver qual arquivo está ocupando a memória
# cd /
# du --threshold=(SIZE)
mencione qualquer tamanho que mostre quais arquivos estão ocupando acima do tamanho limite e exclua o arquivo que você encontrará na memória retida
terminal aberto tente este comando df -Th Em seguida use este comando sudo du -h --max-depth = 1 / neste comando, você encontrará detalhes do uso do disco então abra como usuário root delete o arquivo (root-local-share-trash) e apague seu arquivo