df reporta que uma partição ext4 está cheia, mas não há dados

Question

Recebi recentemente um aviso de que minha partição inicial está cheia. É uma partição Ext4 montada em /home , /dev/sda é um SSD de 240 GB:

hannes@XFLR6 ~> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              19G  5.2G   13G  30% /
none                  3.9G  792K  3.9G   1% /dev
none                  3.9G  2.4M  3.9G   1% /dev/shm
none                  3.9G  712K  3.9G   1% /var/run
none                  3.9G     0  3.9G   0% /var/lock
/dev/sda5             193G  175G  7.9G  96% /home
/dev/sdb5             357G   92G  264G  26% /mnt/schacht

Como você pode ver, df -h (e gparted) informa que /dev/sda5 está 96% cheio. No entanto, o Ubuntu Disk Usage Analyzer e du -h localizam apenas 89 GB de dados. ~/.gvfs está vazio e não há outros sistemas de arquivos montados abaixo de /home . Como pode ser? Eu já tentei executar du como root, mas isso não muda nada.

root@XFLR6 ~# sudo fdisk -l /dev/sda

Disk /dev/sda: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003e4c5

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        2432    19530752   83  Linux
/dev/sda2            2432       28450   208984065    5  Extended
/dev/sda5            2432       27963   205077504   83  Linux
/dev/sda6           27963       28450     3905536   82  Linux swap / Solaris

Editar: whoops - Eu só executei du em ~ não em /home - muitos dados foram copiados involuntariamente para /home . Meu mal, desculpe.

    

Answer 1

Pode ser que algum processo ainda tenha arquivos excluídos abertos. Se esse for o caso, eles não aparecerão na saída du , mas ainda serão contados na saída df .

Uma maneira rápida de verificar isso é listar /proc como usuário root (hint sudo su deve obter um shell raiz). Qualquer arquivo aberto, mas excluído, terá (deleted) no final do nome do destino do link simbólico.

ls -l /proc/*/fd/* | grep deleted | grep /home

deve fornecer uma lista de todos os arquivos abertos. Depois disso, um ls -lL do arquivo específico deve fornecer o tamanho do arquivo.

Como exemplo (usando /tmp no meu sistema porque não há exemplos em /home aqui), vejo alguns arquivos pertencentes ao usuário mysql .

richm@viking:/$ sudo su
root@viking:/# ls -l /proc/*/fd/* | grep deleted | grep /tmp
lrwx------ 1 root     root     64 Oct 13 06:30 /proc/1489/fd/11 -> /tmp/ibwmCqpg (deleted)
lrwx------ 1 root     root     64 Oct 13 06:30 /proc/1491/fd/12 -> /tmp/ib9MTMQi (deleted)
root@viking:/# ls -lL /proc/1489/fd/11
-rw------- 0 mysql2 mysql2 0 Aug 24 14:09 /proc/1489/fd/11
root@viking:/# ls -lL /proc/1491/fd/12
-rw------- 0 mysql mysql 1320 Oct 15 13:40 /proc/1491/fd/12

Se você tiver algum processo com grandes arquivos excluídos abertos, interromper o processo deve ser suficiente para recuperar o espaço em disco. Alternativamente, uma reinicialização deve fazer o mesmo.

    

Answer 2

Cada sistema de arquivos tem apenas uma certa quantidade de inodes e blocos que podem ser armazenados nele. Mesmo no caso de haver espaço suficiente, você não pode ir mais longe.

Verifique suas configurações com

dumpe2fs /dev/sda5

(apenas as 50 principais linhas são importantes aqui).

Se você tem muitos arquivos pequenos que são menores que o tamanho do bloco, muito espaço é desperdiçado.