Por que é (free_space + used_space)! = total_size em df? [duplicado]

Question

Eu tenho um disco externo USB de ~ 2TB ext4 que tem cerca de metade do tamanho:

$ df 
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdc             1922860848 927384456 897800668  51% /media/big

Eu estou querendo saber porque o tamanho total (1922860848) não é o mesmo que usado + disponível (1825185124)? De esta resposta , vejo que 5% do disco pode ser reservado para o root, mas isso ainda levaria apenas o total usado para 1921328166, que ainda está desativado. Está relacionado a alguma outra sobrecarga do sistema de arquivos?

Caso seja relevante, lsof -n | grep deleted não mostra arquivos deletados neste disco, e não há outros sistemas de arquivos montados dentro deste.

Editar: conforme solicitado, aqui está a saída de tune2fs -l /dev/sdc

tune2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   big
Last mounted on:          /media/big
Filesystem UUID:          5d9b9f5d-dae7-4221-9096-cbe7dd78924d
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:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378624
Reserved block count:     24418931
Free blocks:              480665205
Free inodes:              122101749
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Nov 23 14:13:57 2011
Last mount time:          Wed Nov 23 14:14:24 2011
Last write time:          Wed Nov 23 14:14:24 2011
Mount count:              2
Maximum mount count:      20
Last checked:             Wed Nov 23 14:13:57 2011
Check interval:           15552000 (6 months)
Next check after:         Mon May 21 13:13:57 2012
Lifetime writes:          144 MB
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
Default directory hash:   half_md4
Directory Hash Seed:      68e954e4-59b1-4f59-9434-6c636402c3db
Journal backup:           inode blocks

    

Answer 1

Não há espaço faltando. 5% de reserva é arredondado para o valor mais próximo.

1k blocos: 1922860848

Blocos reservados de 1k: (24418931 * 4) = 97675724

Blocos totais usados: 927384456 + 897800668 + 97675724 = 1922860848

Edit: Quanto ao seu comentário sobre a diferença entre os blocos df e os blocos 'Block Count'.

Portanto, a diferença do bloco de 4k é (1953514496 - 1922860848) / 4 = 7663412

A maior parte da 'diferença' é composta pelo parâmetro "Inode blocks per group", que é 512.

Desde há 32768 blocos por grupo que coloca o número de grupos em 488378624/32768 que é 14904 arredondado para baixo.

Multiplicado pelos 512 blocos ocupados, fornece 7630848 blocos.

Isso nos dá 7663412 - 7630848 = 32564 não contabilizados. Eu suponho que esses blocos formam o tamanho do seu diário, mas não tenho certeza disso!

    

Answer 2

Se você estiver usando um sistema de arquivos de registro no diário (ext3, ext4, etc), o diário ocupará espaço;