Disco se enchendo lentamente, mas nenhuma alteração visível no tamanho do arquivo

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

Esses 77% foram apenas 60% ontem e serão preenchidos até 100% em alguns dias.

Estou monitorando o tamanho do arquivo há algum tempo:

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

Está me dando (mais ou menos) os mesmos números todos os dias. Esse total de 14G é menos da metade do tamanho do disco. Para onde está indo o resto?

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

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

Se houver um crescimento invisível no espaço em disco, um provável culpado seria os arquivos excluídos. 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 limpa de limpar você mesmo - as falhas no aplicativo não impedem a limpeza de arquivos temporários.

Para examinar arquivos excluídos ainda usados:

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

Você pode ter um grande número de arquivos excluídos - isso por si só não é um problema. Um único arquivo excluído ficando grande é um problema.

Uma reinicialização deve corrigir isso, mas se você não deseja reinicializar, verifique os aplicativos envolvidos (primeira coluna na lsofsaída) e reinicie ou feche os de aparência razoável.

Se você vir 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 uma fonte de uso de disco grande (mas você ainda deve reiniciar o programa para que as correções sejam aplicadas).

Arquivos /dev/shmsã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 nomeados vteXXXXXXsão arquivos de log de um emulador de terminal baseado em VTE (como GNOME Terminal, Terminator, etc.). Estes podem ser grandes, se você tiver uma janela de terminal aberta com muitas (e eu quero dizer muitas ) coisas sendo produzidas.

Para adicionar à excelente resposta de muru:

• df mostra o tamanho do 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 -ie veja se o número de inodes (ou seja, de arquivos) também aumenta muito as horas extras)

Se você tiver, digamos, 1'000'000 (1 milhão) de minúsculos arquivos de 1 byte, ducontará isso como 1'000'000 bytes no total, digamos 1Mb (... puristas, por favor, não se contorça)

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

• 1 inode (apontando para os dados do arquivo), e esse inode por si só pode ter 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 (geralmente ...), portanto, seus 1 byte de dados ocuparão pelo menos 1 bloco

Assim, um milhão de arquivos de 1 byte ocupará 1'000'000'000 * size_of_a_blockespaço total para os dados, mais 1'000'000'000 * size_of_an_inodeo tamanho do inode ... Isso pode equivaler a vários Gb de uso do disco para 1 milhão de arquivos de "1 byte".

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

Se /dev/vda1estiver sendo preenchido, pode ser causado por Jenkins ou Docker (ou etc) e talvez você precise usar o lsofcomando para limpar logs e definir seu tamanho .