ext4: onde foi meu espaço livre?

Question

Acabei de atualizar minha VM Mageia 2 de 64bits para Mageia 3, e agora meu espaço livre em disco virtual é quase nulo, embora menos de 100% do espaço seja usado.

Eu não sou um especialista em sistema de arquivos ext4, mas extraí todas as informações relevantes que eu poderia imaginar abaixo:

Saída do comando df -h / (:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        11G  9.9G     0 100% /

Apenas no caso, a mesma saída sem a opção -h :

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       10645080 10353564         0 100% /

Agora com a opção -i :

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda1        670K  338K  332K   51% /

No meu entendimento, eu deveria ter:
-11G - 9.9G = espaço livre de 1.1G para arredondar ou arredondar, até margem de erro de .1G ou -11G - 9.9G - .05 * 11G = 0.55G (para ter em conta a percentagem de blocos reservados (5% no meu caso - opção de distribuição por defeito)

Eu nem sou capaz de criar qualquer arquivo.

Além disso, eu deletei entre 300-500 MB de arquivos desde que me deparei com esse problema "sem espaço livre", mas o espaço livre mostra 0, embora tenha sido negado a criação de qualquer arquivo desde (logado como root) ! Eu também reiniciei o sistema várias vezes para levar em consideração os arquivos excluídos que ainda podem ter sido abertos enquanto foram excluídos, mas não houve alteração no espaço livre relatado. Finalmente, desde a primeira ocorrência do problema, o tempo de atividade foi de, no máximo, 12 horas e du -h /var/log fornece 38M, portanto, não há loucura de log aqui.

As primeiras linhas de dumpe2fs output fornecem:

dumpe2fs 1.42.7 (21-Jan-2013)
Filesystem volume name:   <none>
Last mounted on:          /sysroot
Filesystem UUID:          45b03008-87fa-4684-a98a-bd5177e2b475
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              685440
Block count:              2737066
Reserved block count:     136853
Free blocks:              88348
Free inodes:              339326
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      668
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Flex block group size:    16
Filesystem created:       Mon Aug 20 12:34:41 2012
Last mount time:          Wed May 29 14:29:19 2013
Last write time:          Wed May 29 14:09:03 2013
Mount count:              44
Maximum mount count:      -1
Last checked:             Mon Aug 20 12:34:41 2012
Check interval:           0 (<none>)
Lifetime writes:          66 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       46157
Default directory hash:   half_md4
Directory Hash Seed:      bc061f51-9d12-4851-a428-6fb59984118b
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00015d7c
Journal start:            17427

Por fim, tentei brincar com as contagens de bloco reservadas para o caso e aqui está a saída:
Comando: tune2fs -m 0 /dev/sda1 && /usr/bin/df / && tune2fs -m 5 /dev/sda1 && /usr/bin/df /

tune2fs 1.42.7 (21-Jan-2013)
Setting reserved blocks percentage to 0% (0 blocks)
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       10645080 10353576    291504  98% /
tune2fs 1.42.7 (21-Jan-2013)
Setting reserved blocks percentage to 5% (136853 blocks)
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       10645080 10353576         0 100% /

Então, aparentemente, definindo porcentagem de blocos reservados para 0, posso recuperar cerca de 285M, mas isso não corresponde à matemática do pior caso, incluindo a porcentagem de blocos reservados, conforme o entendo: 11G - 9.9G - .05 * 11G = 0.55G. Também não me diz por que depois de deletar arquivos de 300 ~ 500M eu ainda não consigo criar nenhum arquivo e o espaço livre é mostrado como '0'. Lembre-se que, em qualquer caso, eu estou logado como root, então eu entendo que eu deveria ser capaz de usar o espaço reservado (não é uma boa idéia, mas apenas como um princípio).

Alguma pista do que está acontecendo aqui? Pode estar relacionado (e como) com a enorme quantidade de alterações de disco no tamanho dos dados e nas criações / exclusões de arquivos ocorridas durante a atualização da distribuição ou na /usr migração na Mageia 3 (não é possível entender por quê, como /usr está no mesmo sistema de arquivos que / (não uma partição separada)?

    

Answer 1

Você está jogando com blocos reservados , e tentando controlá-lo via espaço dentro do df com valores arredondados.

10645080-10645080*0.05=10112826 blocks are available for normal user

e você tem 10353576 blocos usados, portanto é normal.

Também df arredonda valores. você tem 10645080 blocos 1K e é arredondado para 11G.

Realmente é 10645080/1024/1024 = 10.15G, não 11G.

Você pode executar df -BM para verificar o tamanho em MB, ele é arredondado com muito menos imprecisão.