df o comando mostra 100% cheio, mesmo depois de deletar arquivos mostra o mesmo uso (100%)

Question

A partição de armazenamento Nand Flash é exibida como 100% cheia com o comando df. Quando calculado manualmente, o uso é de cerca de 7-80% (max) apenas. Excluídos alguns arquivos (digamos em torno de 50 ~ 60MB), a saída do comando ainda df não foi alterada. Eu não posso criar um novo arquivo, erro: "não há espaço no dispositivo de armazenamento". Tentei o comando sync , sem diferença.

Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                   262144     20780    241364   8% /tmp
tmpfs                      512         0       512   0% /dev
/dev/ubi0_0            1275540   1275540         0  100% /storage

Quando o espaço de armazenamento real não está cheio (de acordo com o cálculo manual), por que o comando doe df mostra como 100% cheio?

    

Answer 1

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:

1. Um processo em execução chamado xyz.service está usando um arquivo chamado something.dump , que está na partição /storage .

2. A file discriptor de something.dump está listada na process file discriptor table de xyz.service .

3. Você excluiu something.dump , mas xyz.service ainda está em execução.

4. O xyz.service não está ciente do satus atualizado do arquivo something.dump . Então, o discriptor de arquivo de something.dump ainda está lá.

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

6. O kernel viu que o fd de something.dump ainda está na tabela xyz.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.

7. Então, quando você fizer o sigkill xyz.service , esses inodes serão liberados e você provavelmente poderá ver os espaços livres.

8. Reiniciar o sistema fará o mesmo que o passo 7.