Arquivos excluídos de casa, excluídos de .local / share / Trash / files, o sistema não reporta o espaço livre

Question

Estou executando o Crunchbang, uma variante do Debian com o OpenBox WM. Eu apaguei um grande número de arquivos via navegação no gerenciador de arquivos thunar e pressionando a tecla del. Eles desaparecem de vista. Eu então vou para ~ / .local / share / Trash / files / e os excluo de lá também. O sistema de arquivos ainda não reporta o espaço liberado.

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb5              61G   57G  371M 100% /

    

Answer 1

Uma vez eu tive um problema semelhante tentando rastrear o que estava ocupando espaço na minha partição raiz, mas não sendo relatado pelo Baobab, um analisador de uso de disco. No final, encontrei os arquivos na minha pasta de lixo do usuário root, /root/.local/share/Trash . A razão pela qual o Baobab e outros utilitários não mostrariam esses arquivos é porque eu os estava executando como um usuário não-root e eles não tinham as permissões necessárias para ler a pasta /root . Um rápido su me permitiu entrar no diretório necessário e rm * os arquivos de distância.

    

Answer 2

Um possível motivo é que o ext2 / 3/4 e outros "sistemas de arquivos Unix" reservam uma certa quantidade de espaço para o root - acredito que o padrão seja 5%. Dessa forma, o usuário-raiz e os processos executados pelo root ainda têm espaço para manobra, mesmo quando o sistema relata que o sistema de arquivos está cheio e se recusa a deixar que usuários normais (não-root) escrevam algo.

Isso é ótimo para alguns sistemas de arquivos - como / (root), / var e se você tem tudo em um sistema de arquivos ... pode ser menos ideal para sistemas de arquivos / home e / usr, que provavelmente devem ser menos reservados espaço (talvez apenas 1% ou nenhum).

Em qualquer caso, quando comandos como df reportam "0 bytes livres" e "100% usados", isso não inclui estes 5% reservados para root! Assim, enquanto os usuários normais são bloqueados, o usuário-raiz e os processos executados como root podem continuar a escrever - aparentemente preenchendo a partição acima de 100%.

Isso significa que o disco não está tão cheio quanto você pode pensar ... Mas isso também significa que a exclusão de arquivos pode não ter tanto impacto quanto você pensou; simplesmente porque alguns dos arquivos que você excluiu são arquivos escritos acima do limite total de 100% e, portanto, não aparecem com df depois.

Portanto, se o seu disco tiver 100 GB de espaço efetivo, df mostrará apenas 95 GB. No entanto, depois de preencher esses 95 GB e df mostrar o disco como cheio e o sistema recusar usuários normais a gravar nele, o root ainda poderá gravar outros 5 GB. Se você limpar e excluir 10 GB de arquivos, df ignorará os 5 GB reservados para o root e mostrará apenas 5 GB (não 10 GB) como sendo liberados. Então eu suponho que você tenha usado algum espaço reservado para root, então quando você deletou 7GB, apenas 378MB ficou abaixo do limite reservado.

Você pode usar tune2fs para alterar quanto espaço deseja reservar para o root - deve ser algum (talvez não seja de 5%). Há também opções para mke2fs que permite definir quanto espaço reservar em porcentagem ou bytes ao criar o sistema de arquivos (formatar a partição). 5% fizeram mais sentido quando os discos eram menores - com discos de 500 GB + 5% se torna um pouco demais.

    

Answer 3

você pode executar este comando para ver quanto cada diretório ocupa o espaço do seu disco:

du -hc --max-depth=1

quando você encontrar o diretório com tamanho estranho, execute este comando e remova os arquivos que você não precisa mais.

se nada for encontrado, execute o comando no diretório / . postar a saída, se necessário.

Você também pode usar o Bleachbit, experimente: Bleachbit

    

Answer 4

Bem, valeria a pena tentar, então pensei em postar aqui:

# find /root/.local/share -name '*.trashinfo'

Estas são criaturas desagradáveis. Pessoalmente, eu os encontrei quando iniciei okteta (editor hexadecimal) no modo de console e kio_trash inundou meu terminal com muitas "informações" inúteis sobre cannot stat: ... messages, i. e. não ser capaz de encontrar arquivos (que eu tinha excluído LONG atrás). A "solução" era que ela persistentemente procurava em $HOME/.local/share/Trash/info por .trashinfo arquivos. Quando fiz uma limpeza completa no diretório info , a paz reinou na minha caixa linux novamente. :) Quem inventou esse absurdo, deve ser provocado.