O que está ocupando tanto espaço no meu disco, além do sistema de arquivos?

20

Eu tenho apenas um disco no meu computador, um SSD de 80 GB. Ele está formatado como uma única partição ext4 (sem troca) e todas as pastas habituais estão instaladas nela (eu mantenho muitos dados em mídia externa, mas / home e todo o resto está no SSD).

Hoje eu iniciei e recebi a mensagem de que a unidade está cheia. Abri o Disk Usage Analyzer para ver o que ocupa espaço. Ele insiste que 67,8 GB do disco são usados ​​e que / está ocupando 36,4 GB. O que leva à pergunta: onde estão os 30 GB ausentes, se não estiverem no sistema de arquivos ?!

Apenas para fazer uma comparação, adicionei todos os tamanhos de todas as pastas legíveis listadas no Nautilus como subpastas de / (incluindo as ocultas). Eu tenho 20,9 GB. O lixo estava ilegível, mas eu sei que ele tem 16,2 GB, então a soma é 36,1 GB, aproximadamente o mesmo que o Analisador de Uso de Disco está relatando. Havia algumas pastas do sistema que eram ilegíveis, como proc, mas duvido que elas adicionem até 30 GB - caso contrário, não seria possível instalar o Ubuntu em pequenos discos, e eu o vi rodar em 2,5 GB. Acho que devem ser a diferença de 0,3 GB entre o meu cálculo e o relatório do Analisador de Uso de Disco.

Então, eu gostaria de saber o que está consumindo esses 30 GB e como faço para liberá-los?

texto alternativo

Edite com respostas para as perguntas de CYREX

  1. Inicializado a partir do Ubuntu 10.10 Live CD de 64 bits (igual ao meu sistema).

    resultado fsck: 

    root@ubuntu:~# fsck /dev/sda1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
/dev/sda1: clean, 265956/4890624 files, 18073343/19537408 blocks

  2. Inicializado a partir do SDD. Esvaziou o lixo, e os 16 GB de lá agora estão livres. Os 30 GB ainda estão faltando.

    texto alternativo

  3. Não tenho experiência suficiente para saber o que conta como estranho em um log. Aqui estão o meu log de mensagens e meu syslog desde a última inicialização, talvez você possa encontrar algo neles:

  4. Aqui ficou realmente estranho. Liguei um disco rígido externo de 500 GB. O Disk Usage Analyzer supernotificou o espaço disponível e mostrou o espaço ausente (76 GB usados, mas apenas 24 em pastas).

    texto alternativo

Inicializado novamente a partir do LiveCD, iniciou o Disk Usage Analyzer a partir dele e obteve os mesmos resultados do Ubuntu instalado, dentro de 1-2 GB.

Edite com resposta ao CodeMonk

Seria uma boa solução, mas a partição é realmente de 80 GB - quero dizer "erro" de marketing de 74 GB +, de qualquer maneira todo o disco está formatado. Também mostra que mais de 50 GB são usados ​​- então, onde estão os 30 GB, se não estiverem em arquivos e pastas?

texto alternativo GParted também relata o tamanho correto do disco rígido externo.

texto alternativo

disk-usage rumtscho
fonte
Às vezes é melhor não confiar nas ferramentas da interface gráfica do usuário, abrir um terminal e executar, obter um relatório resumido do espaço usado por diretório na raiz: sudo du -sm / *
João Pinto
3
Ao não expandir a entrada do Disk Usage Analyzer para /sua primeira e segunda capturas de tela, você se cega (e a nós) aos tamanhos de todos os diretórios subordinados que o gráfico de anel mostra claramente como ocupado por alguma coisa. Poderia ser algo tão simples quanto o / var / log / syslog sendo preenchido com algum hardware extremamente reclamante, mas precisamos desses dados.
quer
Você já tentou procurar os arquivos de log? Lembro que meu switch KVM e o teclado sem fio não estavam funcionando bem juntos após uma reinicialização, o que causou o crescimento de um arquivo de log e o preenchimento de todo o espaço (após dois dias). A substituição do dispositivo ajudou. Pode ser diferente para o seu servidor, mas espero que lhe dê uma dica.
LiveWireBT

Respostas:

33

Se você usa o Disk Analyzer como usuário normal, pode haver alguns arquivos que você não pode acessar ou visualizar. Você pode tentar iniciá-lo com privilégios de superusuário. Abra um terminal ou pressione ALT + F2 e digite:

gksudo baobab

Baobab é o nome nerd do Disk Analyzer, se você está se perguntando. Talvez agora possa mostrar onde estão esses megabytes ausentes.

Javier Rivera
fonte
11
Lembre-se também de que outro atalho para abrir seu terminal no Ubuntu é Ctrl + Alt + T.
Yufenyuy Veyeh Dider
17

Eu resolvi isso - graças a todos os seus conselhos, especialmente o de Javier Riveira, que sugeriu executar o Disk Analyzer com direitos de sudo (eu não sabia que isso poderia ter influência nos resultados).

Eu tenho o Crashplan e está fazendo backups para algumas das unidades externas. Portanto, há um conjunto de backup que vai para Milly e outro para Sto_Lat, uma vez a cada 15 minutos (esses são os nomes das unidades externas). Quando, em algum momento, iniciei o computador sem essas unidades, o Crashplan não encontrou pastas em baixo /media/Millye /media/Sto_Lat, portanto, apenas as criou e criou backups para elas.

Por algum motivo, o Disk Analyzer não mostra essas pastas quando iniciado sem o sudo. O Nautilus mostra, mas lista o tamanho de /media16 KB, quando na verdade é de 30 GB.

Só notei isso quando desmontei todas as unidades externas, incluindo Milly e Sto_Lat, e iniciei gksudo baobab. Então vi minhas unidades externas onde não deveria haver nenhuma - mas não todas, mas apenas os destinos de backup - e percebi que essas não são unidades montadas, mas pastas de mesmo nome criadas pela Crashplan. Deve haver algo estranho acontecendo quando eu monto a unidade com o mesmo nome da pasta existente. Gostaria de saber por que não recebo uma mensagem de erro ou algo assim ...

BTW, isso também resolve porque o Disk Analyzer mostra os tamanhos de Milly em 530 GB em vez de 500 GB - esses são os 30 GB "ausentes", que contam a pasta e a unidade real juntos.

Agora eu só preciso de uma maneira de excluir as pastas sem interromper o Crashplan ou permanecer sem backups.

rumtscho
fonte
Você deve marcar isso como a resposta aceita. Adicionei um link à resposta de Javier para que ele receba votos positivos pela dica.
Jorge Castro
Este é exatamente o mesmo problema que tive. Um dos meus discos de backup morreu, mas meu script de backup ainda tentou fazer backup na pasta / mnt / Backup-Drive, preenchendo meu disco raiz.
22713 Michael Robinson
O motivo sudoé que as partes do sistema de arquivos não podem ser lidas pelo usuário em que você está executando. Isso faz todo o sentido, imagine se algum usuário pudesse ler seus backups completos, por exemplo.
Arielf
@arielf Acho que nunca pensei muito nisso. Mas espero que um utilitário de contagem de espaço em disco me forneça uma imagem precisa do espaço em disco usado e livre, talvez exibindo um blob cinza dizendo "esta parte está cheia, mas você não tem o direito de ver o que está lá". Fico bastante surpreso como usuário quando os arquivos que não tenho o direito de ler são contados no espaço livre em disco.
rumtscho 7/09/15
Bem, você pode simplesmente executar o dfque não faz uma verificação completa do diretório e fornece apenas o espaço total vs livre de uma partição. Mas se você deseja uma verificação completa do diretório, com os detalhes fornecidos por baobabou filelight(no nível do arquivo individual), são necessárias permissões completas de leitura para os diretórios.
Arielf
5

Você pode usar o Disk Usage Analyzer para verificar seus diretórios e ver para onde está indo o seu espaço no sistema de arquivos.

texto alternativo

Quanto a não conseguir ver 30 GB do seu disco, abra o GParted e veja como o espaço está alocado no disco. Pode ser que o seu esquema de partição não seja o que você pensava.

GParted

Nick Pascucci
fonte
GParted foi uma boa idéia, mas o mistério permanece, veja a captura de tela
rumtscho
Isso é realmente muito estranho. O analisador de uso do disco mostra arquivos grandes no diretório raiz?
Nick # # # # # # Pascucci #
4

Você pode usar dupara mostrar isso:

cd /
sudo du -hcsx .[!.]* * | sort -rh | head

ou

sudo du -hcsx * | sort -rh | head

Isso mostrará o que está usando mais espaço.

mchid
fonte
3

Como padrão, há 10% do seu espaço em disco reservado para o usuário root. Você pode mudar isso usando sudo tune2fs -m %percentage %device. No seu caso, isso seria sudo tune2fs -m 1 /dev/cciss/c0d0p1reduzir a reserva para 1%. Você pode configurá-lo para qualquer outro número que desejar, mas eu não recomendaria 0%.

André Stannek
fonte
Os resultados 'sudo du -chs /' têm algo com que se preocupar?
Dannymcc
Eu não sei, mas se você não tem quaisquer outros problemas que eu não me importaria ;-)
André Stannek
1

Faça o seguinte em deixe-me saber como foi:

  1. Insira um LiveCd e fsck seu / dev / sda1
  2. Limpe sua lixeira.
  3. Veja o Log File Viewer para ver coisas estranhas que estão acontecendo.
  4. Teste (se você puder) com um HDD normal (não SSD). Apenas para remover essa opção.

Deixe-me saber como foi.

Luis Alvarado
fonte
Poste as informações solicitadas, consulte a edição na pergunta.
rumtscho 15/12/10
1

Realmente não sei se isso ajuda você, mas no meu caso também experimentei isso, meu HDD estava perdendo espaço livre ao longo do tempo sem uma razão. Aconteceu que as configurações padrão no gerenciador de pacotes sinápticos também contribuíram para isso. As configurações padrão nas preferências, na guia arquivo instruirão o synaptic a manter todos os pacotes baixados no cache . Com o tempo, isso pode acumular uma bela montanha de arquivos. Alterei as configurações para excluir os pacotes baixados após a instalação . Isso ajudou a recuperar uma boa quantidade de espaço livre.

Novamente, eu realmente não tenho certeza se isso ajuda no seu caso, mas você pode verificar o cache sináptico, talvez esteja cheio de arquivos obsoletos.

AndyB
fonte
11
interessante saber, mas esse cache seria contado como parte do sistema de arquivos.
rumtscho