Disco preenchendo lentamente, mas sem alterações visíveis no tamanho do arquivo

Question

  

df

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

Que 77% estavam com apenas 60% ontem e vai encher até 100% em alguns dias.

Eu tenho monitorado filessizes por um tempo agora:

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

Tem me dado (mais ou menos) os mesmos números todos os dias. O total de 14G é menor que a metade do tamanho do disco. Onde está o resto?

Meu conhecimento em Linux não é muito mais profundo.

É possível que arquivos não apareçam aqui? É possível ter espaço alocado de alguma outra forma?

    

Answer 1

Se houver um aumento invisível no espaço em disco, um provável culpado seria excluir arquivos. No Windows, se você tentar excluir um arquivo aberto por algo, você receberá um erro. No Linux, o arquivo será marcado como excluído, mas os dados serão retidos até que o aplicativo seja liberado. Em alguns casos, isso pode ser usado como uma maneira simples de limpar o seu conteúdo - as falhas de aplicativos não impedem arquivos temporários.

de ser limpo.

Para ver os arquivos excluídos e ainda usados:

lsof -b 2>/dev/null | grep deleted

Você pode ter um grande número de arquivos excluídos, o que em si não é um problema. Um único arquivo excluído ficando grande é um problema.

Uma reinicialização deve corrigir isso, mas se você não quiser reinicializar, verifique os aplicativos envolvidos (primeira coluna em lsof output) e reinicie ou feche os arquivos com aparência razoável.

Se você já viu algo como:

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

Onde o aplicativo e os arquivos excluídos são os mesmos, isso provavelmente significa que o aplicativo foi atualizado. Você pode ignorá-los como fonte de uso de disco grande (mas você ainda deve reiniciar o programa para que as correções de bugs sejam aplicadas).

Os arquivos em /dev/shm são objetos de memória compartilhada e não ocupam muito espaço no disco (um número de inode no máximo, eu acho). Eles também podem ser ignorados com segurança. Os arquivos denominados vteXXXXXX são arquivos de log de um emulador de terminal baseado em VTE (como o Terminal GNOME, o Terminal, etc.). Estes poderiam ser grandes, se você tiver uma janela de terminal aberta com lotes (e eu quero dizer lotes ) de coisas sendo saída.

    

Answer 2

Para adicionar a excelente resposta de muru:

• df mostra o tamanho no disco,
• e du mostra o tamanho total do conteúdo dos arquivos.

Talvez o que você não vê com du seja a aparência de muitos, muitos arquivos pequenos ... (veja a última coluna de df -i e veja se o número de inodes (isto é, de arquivos) aumenta muito horas extras também)

Se você tiver, digamos, 1'000'000 (1 milhão) minúsculos arquivos de 1 byte, du contará que, como 1'000'000 bytes no total, digamos 1Mb (... puristas, por favor não se encolha)

Mas no disco, cada arquivo é composto de duas coisas:

• 1 inode (apontando para os dados do arquivo), e esse inode pode ser 16kb (!),
• E os dados de cada arquivo (= o conteúdo do arquivo) são colocados em blocos de disco, e esses blocos não podem conter vários dados de arquivo (normalmente ...), portanto seu 1 byte de dados ocupará pelo menos 1 bloco

Assim, arquivos de 1 byte de um milhão de arquivos ocuparão 1'000'000'000 * size_of_a_block de espaço total para os dados, mais 1'000'000'000 * size_of_an_inode do tamanho do inode ... Isso pode atingir vários GB de uso de disco para 1 milhão de "1 byte" arquivos.

Se você tiver blocos de 1024 bytes e outros 256 bytes de tamanho de inode, seus arquivos de 1'000'000 serão reportados como aproximadamente 1Mb por du , mas contarão como aproximadamente 1.25Gb em disco (como visto por df )! (ou mesmo 2Gb se cada inode também tem que estar em 1 bloco de disco dedicado ... Eu não sei se esse é o caso)