ext4 tamanho da partição / espaço livre discrepâncias

Question

Ao criar uma partição de backup de 250GiB para meus dados, notei muitas discrepâncias entre o tamanho da partição reportada e o espaço livre no Nautilus, gParted, df, tune2fs, etc.

No começo eu pensei que era uma confusão de GiB / GB. Não foi .

Então eu pensei que poderia ser blocos reservados do ext4. Não foi .

Estou completamente confuso. Aqui estão algumas imagens. Aqui estão os passos:

• Primeiro, NTFS. 524288000 setores x 512 bytes / setor = 268435456000 bytes = 268,4 GB = 250 GB.

O Nautilus diz " Capacidade Total: 250.0 GB " (embora seja realmente GiB, não GB). Além dessa pequena rotulagem, até agora, tudo bem

• Agora, a partição mesmo , formatada como ext4 com gparted:

Primeiro,ossetoresLasteTotalsãoosmesmos.Éamesmapartiçãode250GiB.Otamanhousadoé4.11GiB(blocosreservados,talvez?)

Não. Parece que os blocos reservados são 12,7 GiB (~ 5%. ai! ). Mas ... por que a capacidade total é agora apenas 246.1 GiB ??? . Essa diferença (tipo de) corresponde ao 4.11 GiB relatado por gparted. Mas ... se não é de blocos reservados, o que é isso? E por que o gparted não relatou que 12.7GiB de espaço usado?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

df corresponde ao Nautilus no espaço livre relatado. Mas .. apenas 188M usado? Não deve ser ~ 12GB? E a capacidade total ainda está errada. Então eu corri tune2fs para encontrar algumas pistas. (saída irrelevante é omitida)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 total de blocos * 4096 bytes / bloco = 268435456000 bytes = 268,4 GB = 250 GB. Corresponde ao gparted.

3276800 blocos reservados = 13421772800 bytes = 13,4 GB = 12,5 GiB. Ele (mais uma vez, mais ou menos) corresponde ao Nautilus.

64459851 blocos livres = 264027549696 bytes = 264,0 GB = 245,9 GiB. Por quê? Não deveria ser 250-12,5 = 237,5 (ou 250- (12,5 + 4,11) = ~ 233)?

Removendo blocos reservados:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

Como esperado, a mesma contagem de blocos, 0 blocos reservados, mas ... os mesmos blocos livres ? Não acabei de liberar 12,5 GiB?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

Parece que eu fiz. O espaço disponível subiu de 233 para 245,9 GiB. O gparted não se importou, mostrando exactamente a mesma informação! (inútil postar uma captura de tela idêntica)

Que confusão enorme!

Eu tentei documentar da melhor forma que pude ... Então, por favor alguém pode me dar alguma pista sobre o que está acontecendo aqui?

• Quais são os misteriosos 4.11 GiB ausentes do NTFS - > formatação ext4?
• Por que existem tantas discrepâncias entre o gparted, o Nautilus, o tune2fs, o df?
• O que há de errado com minha matemática? (perguntas em negrito espalhadas neste post)

Qualquer ajuda é apreciada. Enquanto eu não consigo entender o que está acontecendo, eu estou pensando seriamente em desistir do ext4 em favor do NTFS para tudo exceto minha / partição.

Obrigado!

    

Answer 1

Existem algumas coisas acontecendo aqui. gparted reporta o espaço usado / livre real. O kernel reduz a contagem disponível pelo espaço reservado. Depois que você removeu o espaço reservado, a contagem livre não foi alterada porque os blocos reservados já estavam livres; é justo que usuários não-root não tenham permissão para invadir esse espaço para evitar que eles causem problemas preenchendo o disco. Os números do gnome são um pouco escamosos por causa de um bug . Em vez de reportar o espaço usado que o kernel reporta (e df mostra), ele calcula subtraindo o espaço livre do total. Isso faz com que ele mostre o espaço reservado conforme usado.

A falta de 4GB é usada na verdade é a sobrecarga de fs para o ext4. O NTFS apenas aloca inicialmente uma pequena quantidade de espaço para a MFT e aumenta conforme necessário. A série ext de sistemas de arquivos, no entanto, aloca espaço para a tabela de inode (equivalente aproximado da MFT) no momento do formato e não pode crescer. O espaço que falta no espaço total relatado é a tabela de inodes. O bit restante do espaço usado é do diário (geralmente 128 mb) e redimensiona inodes.

    

Answer 2

Primeiro de tudo, o bloco de blocos reservados não é usado para o gerenciamento interno do sistema de arquivos.

Os blocos reservados são simplesmente reservados para root , para assegurar que os serviços que usam arquivos nessa partição não possam ser excluídos do espaço por algum usuário não administrador que ocupe todo o espaço.

Mesmo sem blocos reservados ( -m 0 ) há sempre uma parte do espaço usado para o gerenciamento interno do sistema de arquivos, não posso dizer quanto, eu não tenho um conhecimento tão profundo.

Além disso, Gparted é executado como root , então ele vê blocos reservados como livres. Nautilus , executado como usuário, vê-os como não livres.

Ok, a resposta do @psusi é muito clara, não tenho nada a acrescentar.

    

Answer 3

Tente reduzir o tamanho da partição em alguns megabytes usando o gparted e, em seguida, aumente-a novamente para o tamanho original. Isso pode fazer com que outros aplicativos leiam os tamanhos corretamente. Eu recentemente corrigi um erro de 50Gb dessa maneira!