O que está comendo meu espaço em disco?

11

Estou executando o Linux Mint 14 Nadia. A partição do Linux tem 10G. Quando o sistema é iniciado, du informa 80% de uso. Em seguida, o uso cresce lentamente até atingir 100% e o sistema se torna inutilizável. (Isso pode acontecer na ordem de dias ou semanas). Após a reinicialização, o uso é redefinido para 80%.

O mais estranho de tudo é que du não mostra alterações.

Aqui está a saída desses comandos (as partições do Windows e da unidade externa são eliminadas):

# --- Just after reboot ---

$ df -h     
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  7.3G  2.0G  80% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M  288K  437M   1% /run/shm
none            100M   12K  100M   1% /run/user

$ sudo du -x   -d1 -h /
186M    /opt
512M    /var
11M /sbin
556K    /root
1.3G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
60K /tmp
9.1M    /bin
4.0K    /srv
7.3G    /            # <-- note this


# --- After some time ---

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  9.1G  199M  98% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M   27M  411M   7% /run/shm
none            100M   28K  100M   1% /run/user

$  sudo du -x   -d1 -h /
186M    /opt
511M    /var
11M /sbin
556K    /root
1.4G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
520K    /tmp
9.1M    /bin
4.0K    /srv
7.3G    /              # <-- note this

(Nota: eu uso hibernação. Após a hibernação, o uso permanece o mesmo, e após a reinicialização, ele é redefinido para 80%.)

Como faço para acompanhar o que come o espaço?

Li esta questão . Eu ainda estou no escuro. Como descubro qual programa é responsável por esse comportamento?

Após a edição : foi encontrado. O espaço é reivindicado pelo log do kernel, que é visto por dmesg . Ele enche porque minha máquina gera erros na taxa de 5 por segundo. (Está relacionado com este bug .) Deixe os futuros leitores com um problema semelhante - preenchendo lentamente o espaço em disco invisível por du - não se esqueça de tentar dmesg na busca pela causa.

    
por Arry 06.02.2014 / 14:22

5 respostas

12

Execução repetida de

sudo du -x   -d1 -h /

(na árvore de diretórios) deve informar onde o espaço é consumido. Isso provavelmente explica sem mais investigações qual aplicativo está causando isso.

arquivos invisíveis

Se du não mostrar esses arquivos, uma das possibilidades são os arquivos excluídos. Um arquivo (ou melhor: seu nome, ou seja, sua entrada em um diretório) pode ser excluído enquanto o arquivo ainda estiver em uso. Contanto que haja um descritor de arquivo válido apontando para este arquivo, ele cobre o espaço no volume (se não for um arquivo vazio ...).

cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0

Você pode encontrar esses arquivos com find :

find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n     %l\n' 2>/dev/null

Pode ser um único arquivo enorme ou vários arquivos menores que causam o seu problema. Existem cerca de 30 desses arquivos no meu sistema agora (pertencentes a apenas cinco processos). ls -l mostra o tamanho desses arquivos, mas parece que não é possível obter esse valor em find .

Depois de eliminar o processo, o espaço torna-se disponível para o sistema de arquivos ( df ) novamente.

    
por 06.02.2014 / 14:30
6

Use algo como

lsof -s | grep deleted | sort -k 8

para ver quais processos estão mantendo arquivos excluídos abertos. Os campos importantes são o segundo (PID) e o oitavo (terceiro do último; o tamanho do arquivo).

(Preste atenção nas linhas duplicadas, não as conte duas vezes. Verifique o PID e o caminho do arquivo (último campo) ou o número do inode (do segundo ao último campo).)

Depois disso, se você encontrar um processo que provavelmente é o culpado, podemos ver como corrigi-lo.

    
por 06.02.2014 / 15:12
3
find / -size +10000k -print0 | xargs -0 ls -l -h

Use isso para encontrar recursivamente o que está preenchendo mais de 10 MB + de / (root) e exiba-o com muitos detalhes com ls -l em xargs . Se você escrever 1000000 (2 zeros extras), você pode obter 1GB +, por exemplo.

du / -h --max-depth=1 | sort -h

Você também pode usar du e simplesmente acessá-lo manualmente.

    
por 06.02.2014 / 14:30
1

Sempre que isso acontece, sempre inicio meu foco em determinados subdiretórios. A estrutura do FHS que a maioria das distribuições do Linux adota é definida com isso em mente.

Primeiro, olhe em /var , seguido por /home .

$ sudo du -x -d1 -h /var  | sort -hr'

$ sudo du -x -d1 -h /home | sort -hr'

Você também pode restringir seu foco a subdiretórios nesses locais. Uma vez que você está exausto procurando por lá, eu geralmente movo para /root , e por último os subdiretórios restantes em / .

Se for uma distro baseada no Red Hat, o cache que o yum usa para executar atualizações pode estar consumindo uma grande quantidade de espaço. Você pode usar este comando para limpá-lo:

$ yum clean packages

Outras distros que usam apt podem fazer algo semelhante, apt-get clean .

Eu também executaria este comando na parte superior do diretório / , esse local pode às vezes se tornar a fonte para arquivos de log dispersos.

$ ls -la /

Preste atenção especial aos arquivos de pontos! Coisas nomeadas .blah , por exemplo.

    
por 06.02.2014 / 15:03
0

Eu tenho quase a mesma situação.

No meu caso, o motivo foi o VMware. Um dos outros VMwares na mesma máquina, consumiu os espaços de disco. É por isso que meu uso de espaço em disco foi de 100%.

Após excluir arquivos grandes do VMware do vizinho, ele está funcionando corretamente.

    
por 09.11.2015 / 10:47