Uma reinicialização e reinstalação resolveriam o problema, acredito.
Razão: A razão por trás disso é que df
utilizam statfs (2) chamada do sistema para obter o stat do sistema de arquivos. O que significa que ele verificou os descritores de arquivos de kernel abertos para contar o espaço livre como ele é chamado (df = disk free). Você obterá um resultado diferente se usar du
. df
mostrando 100% usado porque os arquivos foram excluídos ainda não foram liberados do descritor de arquivo do kernel.
Pode estar seguindo scenerio irá ajudá-lo a entender:
-
Um processo em execução chamado
xyz.service
está usando um arquivo chamadosomething.dump
, que está na partição/storage
. -
A
file discriptor
desomething.dump
está listada naprocess file discriptor table
dexyz.service
. -
Você excluiu
something.dump
, masxyz.service
ainda está em execução. -
O
xyz.service
não está ciente do satus atualizado do arquivosomething.dump
. Então, o discriptor de arquivo desomething.dump
ainda está lá. -
Então você executou o comando
df
e o kernel verificou toda a tabela de processos para ver o descritor de campo usado para calcular o espaço livre. -
O kernel viu que o fd de
something.dump
ainda está na tabelaxyz.service
do processo. Por isso, conte algo. O despejo ainda está no sistema de arquivos, portanto, não considera os inodes de algo.dump como livres. Qual é o motivo pelo qual você está vendo 100% de uso. -
Então, quando você fizer o sigkill
xyz.service
, esses inodes serão liberados e você provavelmente poderá ver os espaços livres. -
Reiniciar o sistema fará o mesmo que o passo 7.