Disco cheio no servidor linux, blocos usados são muito menos que blocos avalable

Question

A saída de df é:

[root@backup log]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGro  1889811408 1861658948         0 100% /
/dev/sda1               101086     16235     79632  17% /boot
tmpfs                  1815760         0   1815760   0% /dev/shm

Portanto, o bloco disponível deve ser 28.152.460, mas é 0. Eu tenho deletado uma porcaria de arquivos, e os blocos usados estão diminuindo, mas os restos disponíveis estão em 0.

A saída de df -i é:

[root@backup log]# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/VolGro 487751680 238360803 249390877   49% /
/dev/sda1              26104      37   26067    1% /boot
tmpfs                 219784       1  219783    1% /dev/shm

Portanto, não é falta de inodes.

A saída de lsof + L1 é:

[root@backup log]# /usr/sbin/lsof +L1
COMMAND     PID  USER   FD   TYPE DEVICE SIZE NLINK      NODE NAME
mysqld     2444 mysql    4u   REG  253,0    0     0 268795908 /tmp/ibSlaKC7 (deleted)
mysqld     2444 mysql    5u   REG  253,0    0     0 268795909 /tmp/ibhFuyGr (deleted)
mysqld     2444 mysql    6u   REG  253,0    0     0 268795910 /tmp/ibbNinKL (deleted)
mysqld     2444 mysql    7u   REG  253,0    0     0 268795911 /tmp/ibz1ia55 (deleted)
mysqld     2444 mysql   11u   REG  253,0    0     0 268795912 /tmp/ibM3IHvr (deleted)
crond      2549  root    3u   REG  253,0    5     0 248579098 /var/run/crond.pid (deleted)
yum-updat  2620  root   14w   REG  253,0    0     0 248611115 /var/run/yum.pid (deleted)
ssh       16256  root    0u   CHR  136,0          0         2 /dev/pts/0 (deleted)
ssh       16256  root    1u   CHR  136,0          0         2 /dev/pts/0 (deleted)
ssh       16256  root    2u   CHR  136,0          0         2 /dev/pts/0 (deleted)

Eu não posso rodar 'du' porque 99% do uso do disco está em / var / backups que contém provavelmente ~ 100 milhões de arquivos (algum idiota decidiu rsync codificar do servidor live com diretórios de subversão, então é muito minúsculos arquivos), então a execução do 'du' levaria dias ou semanas.

Alguém tem alguma sugestão sobre como proceder?

    

Answer 1

Se este for um sistema de arquivos ext , o espaço reservado para a raiz padrão será de 5% dos blocos 1889811408, ou 94490570 blocos. Em outras palavras, você tem cerca de 66 GB a mais para excluir antes de df reportar espaço livre disponível .

Use tune2fs -m 1 /dev/mapper/VolGro para diminuir o valor reservado para 1% ou -r NNNN para configurá-lo para um número específico de blocos. É necessário ter espaço reservado suficiente para que o registro possa continuar mesmo após os usuários terem "preenchido" o disco (embora, se você estiver preenchendo o disco como root, isso não salvará você de problemas quando a unidade estiver totalmente cheia)

Outros sistemas de arquivos provavelmente também têm blocos reservados, mas os comandos para ajustá-los serão diferentes.

    

Answer 2

Execute um fsck para ver se o sistema de arquivos está danificado.

    

Answer 3

Se você deletou coisas como arquivos de log do apache - ele requer um reinício do apache antes que o espaço seja "liberado"

    

Answer 4

So available block should be 28.152.460, but it's 0. I've been deleting a crap load of files, and used blocks is going down, but available remains at 0.

Eu suspeito que esses arquivos ainda estavam sendo usados pelo seu serviço quando você o excluiu. Então, basta reiniciar o serviço, o comando df atualizará o espaço disponível.