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

14

Ao criar uma partição de backup de 250GiB para meus dados, notei muitas discrepâncias entre o tamanho da partição relatada 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 os blocos reservados do ext4. Não foi .

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

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

insira a descrição da imagem aqui insira a descrição da imagem aqui

O Nautilus diz " Capacidade total: 250,0 GB " (embora seja realmente GiB, não GB). À parte esse pequeno erro de identificação, até agora, tão bom

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

insira a descrição da imagem aqui

Primeiro, Último e Total de setores são os mesmos. É a mesma partição 250GiB. O tamanho usado é 4.11GiB (blocos reservados, talvez?)

insira a descrição da imagem aqui

Não. Parece que os blocos reservados têm 12,7 GiB (~ 5%. Ai! ). Mas ... por que a capacidade total agora é de apenas 246,1 GiB ??? . Essa diferença (mais ou menos) corresponde aos 4,11 GiB relatados pelo gparted. Mas ... se não é de blocos reservados, o que é? E por que o gparted não informou que 12,7 GiB de espaço usado?

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

dfcorresponde ao Nautilus no espaço livre relatado. Mas .. apenas 188 milhões usados? Não deveria ser ~ 12GB? E a capacidade total ainda está errada. Então eu corri tune2fspara 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 GiB. Corresponde a gparted.

3276800 blocos reservados = 13421772800 bytes = 13,4 GB = 12,5 GiB. (Mais uma vez) 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 ? Eu 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

insira a descrição da imagem aqui

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

Que bagunça enorme!

Tentei documentá-lo da melhor maneira que pude ... Então, por favor, alguém pode me dar alguma pista do que está acontecendo aqui?

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

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

Obrigado!

MestreLion
fonte
@Uri Herrera: você realmente leu minha pergunta, ou pelo menos as primeiras linhas? Este não é um problema de GiB / GB. A partição é de 268,4 GB = 250,0 GiB, não de 246,1
MestreLion
1
Outra resposta que você pode dar uma olhada em: askubuntu.com/questions/5335/…
enzotib
1
Veja também ext4: Como contabilizar o espaço do sistema de arquivos?
Gilles 'SO- stop be evil' (

Respostas:

13

Há algumas coisas acontecendo aqui. O gparted relata o espaço usado / livre real. O kernel reduz a contagem disponível pelo espaço reservado. Depois de remover o espaço reservado, a contagem livre não foi alterada porque os blocos reservados já estavam livres; apenas usuários não raiz não podem invadir esse espaço para impedir que causem problemas, enchendo o disco. Os números do gnomo são um pouco esquisitos por causa de um bug . Em vez de relatar o espaço usado que o kernel relata (e o 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 4 GB é realmente usada é a sobrecarga de fs para ext4. O NTFS inicialmente aloca uma pequena quantidade de espaço para a MFT e aumenta conforme a necessidade. A série ext de sistemas de arquivos aloca espaço para a tabela de inodes (equivalente aproximado da MFT) no momento da formatação e ela não pode crescer. O espaço ausente no espaço total relatado é a tabela de inodes. O bit restante de espaço usado é do diário (geralmente 128 mb) e redimensiona os inodes.

psusi
fonte
Obrigado, +1 por resolver alguns dos mistérios! Mas, se os ~ 4 GB são sobrecarga do sistema de arquivos, por que alguns deles (3,9 GB) são deduzidos do espaço total, enquanto 188 MB são exibidos como realmente usados? Qual (ou ambos) é a sobrecarga? E por que tratado de maneira diferente? Além disso, dfmesmo com o sudo, mostra capacidade total (247 GB) e espaço usado (188 MB) como o Nautilus. Então, se é um bug, não é apenas um gnomo.
MestreLion
Eu pensei que os 188MB eram a sobrecarga (em comparação com os 72MB do NTFS). Mas, se a sobrecarga do NTFS aumentar com o tempo, isso significa que o Nautilus reportaria mais tarde que a capacidade total estava diminuindo ?
MestreLion 13/06
Correção: o df sempre mostra o espaço disponível, independentemente de quem o executa. Para ver o espaço livre (== espaço disponível + espaço reservado), use stat -f /media/BACKUP.
Marius Gedminas
Resposta editada para esclarecer. E acredito que o NTFS reportará apenas mais espaço usado, não diminuirá o total à medida que a MFT cresce. @ Marius, isso também não está correto. statfs () e, portanto, df e stat -f mostram o espaço disponível sem contar os blocos reservados. Eu poderia jurar que também ajustava a cota e variava sua resposta com base no usuário que chamava, mas você está certo sobre isso; ele não conta a cota e não se importa com o que o usuário chama.
psusi
@psusi: então eu tenho ~ 3.9GiB de tabela de inode e ~ 188MB de diário + algo assim? E o Nautilus subtrai a tabela de inodes do Tamanho total, enquanto o diário é reportado como espaço usado? E o gparted os relata como um único 4.11GiB de espaço usado? Isso está correto? Nesse caso, eu apenas desejava que o Nautilus lidasse com as duas despesas gerais da mesma maneira. Ou ambas subtraídas do total ou ambas contadas como "espaço usado" (de preferência).
MestreLion
7

Antes de tudo, os blocos reservados não são usados ​​para o gerenciamento interno do sistema de arquivos.

Os blocos reservados são simplesmente reservados root, para garantir que os serviços que usam arquivos nessa partição não possam ser descartados por um usuário não administrador que preencha todo o espaço.

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

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

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

enzotib
fonte
Humm, muito informativo, +1. Pelo menos isso resolve alguns dos problemas que encontrei. Ver blocos reservados como um "limite máximo" para não-raiz em vez de "blocos usados" faz com que as partições gparted, df e tune2fs concordem (e façam sentido). Mas algumas questões ainda permanecem, especialmente os 4 GB de espaço usado / capacidade total.
MestreLion
1
Além disso, eu li em algum lugar (um daqueles antigos "por que você não precisa desfragmentar sua partição Linux todos os meses", talvez?) Que reservar 5% de espaço para o root dá um pouco de espaço para os algoritmos de alocação extN e, portanto, evita fragmentação.
Marius Gedminas
1

Tente reduzir o tamanho da partição em alguns megabytes usando gparted e depois aumentá-lo novamente para o tamanho original. Isso pode fazer com que outros aplicativos leiam os tamanhos corretamente. Corrigi recentemente um erro de 50 Gb desta maneira!

jim birch
fonte