Por que os sistemas de arquivos ext não preenchem o dispositivo inteiro?

Acabei de notar que qualquer um dos sistemas de arquivos ext {2,3,4} que estou tentando criar no 500G HDD não usa todo o espaço disponível (466G). Eu também tentei reiser3, xfs, jfs, btrfs e até vfat. Todos eles criam fs de tamanho 466G (como mostrado por df -h ). No entanto, ext * cria fs de 459G. Desativar blocos reservados aumenta o espaço disponível para o usuário, mas o tamanho de fs ainda é 459G.

O mesmo vale para o HDD de 1Tb: 932G reiserfs, 917G ext4.

Então, qual é essa diferença de 1,5%? Por que isso acontece e existe uma maneira de fazer o volume inteiro do preenchimento ext?

UPD: Todos os testes feitos na mesma máquina, no mesmo HDD etc. Não importa a diferença entre o 466G e o marketing de 500G. O problema é que difere para diferentes FS '.

Sobre df - mostra o tamanho total da FS, tamanho usado e espaço livre. Neste caso eu tenho:

para reiserfs:

/ dev / sda1 466G 33M 466G 1% / mnt

para ext4:

/ dev / sda1 459G 198M 435G 1% / mnt

Se eu desativar a reserva do bloco raiz, 435G mudará para 459G - tamanho total de fs (menos 198M). Mas o próprio fs ainda é 459G para ext4 e 466G para reiser!

UPD2: preenchendo volumes com dados reais via dd:

reiserfs:

fs: ~ # dd se = / dev / zero de = / mnt / 1
dd: запись в «/ mnt / 1»: а устройстве кончилось место
975702649 + 0 записей считано
975702648 + 0 no total
 скопировано 499559755776 (500 GB), 8705,61 c, 57,4 MB / c

ext2 com a reserva de blocos desativada (mke2fs -m 0):

fs: ~ # dd se = / dev / zero de = / mnt / 1
dd: запись в «/ mnt / 1»: а устройстве кончилось место
960356153 + 0 записей считано
960356152 + 0 записей написано
 Código 491702349824 (492 GB), 8870,01 c, 55,4 MB / c

Desculpe pelo russo, mas eu o executei na localidade padrão e a repetição é muito longa. Não importa, a saída dd é óbvia.

Portanto, o mke2fs realmente cria um sistema de arquivos menor do que os outros mkfs.

Há duas razões para isso ser verdade.

Primeiro, por algum motivo ou outro gravador de SO, ainda relata espaço livre em termos de sistema base 2, e os fabricantes de discos rígidos relatam espaço livre em termos de sistema base 10. Por exemplo, um gravador de sistema operacional chamará 1024 bytes (2 ^ 10 bytes) por kilobyte, e uma fabricação de disco rígido chamaria 1000 bytes por kilobyte. Essa diferença é bem pequena para kilobytes, mas depois que você atinge os terabytes, é bem significativa. Um gravador do sistema operacional chamará 1099511627776 bytes (2 ^ 40 bytes) de terabyte e o fabricante do disco rígido chamará 1000000000000 bytes de terabyte.

Essas duas maneiras diferentes de falar sobre tamanhos freqüentemente causam muita confusão.

Existe um prefixo ISO com suporte para tamanhos binários . As interfaces do usuário projetadas com o novo prefixo em mente mostram TiB, GiB (ou mais geralmente XiB) ao mostrar tamanhos com um sistema de prefixo base 2.

Em segundo lugar, o df -h informa quanto espaço está disponível para seu uso. Todos os sistemas de arquivos precisam gravar informações de manutenção para acompanhar as coisas para você. Essas informações ocupam um pouco do espaço em sua unidade. Geralmente não muito, mas alguns. Isso também explica algumas das perdas aparentes que você está vendo.

Depois de editar sua postagem para deixar claro que nenhuma das minhas respostas realmente responde à sua pergunta, tentarei responder sua pergunta ...

Sistemas de arquivos diferentes usam quantidades diferentes de espaço para informações de limpeza e relatam esse uso de espaço de maneiras diferentes.

Por exemplo, ext2 divide o disco em grupos de cilindros. Em seguida, pré-aloca espaço em cada grupo de cilindros para inodes e mapas de espaço livre. O ext3 faz a mesma coisa, já que é basicamente o diário ext2 +. E o ext4 também faz exatamente a mesma coisa, pois é uma modificação bastante direta (e quase compatível com versões anteriores) do ext3. E como essa sobrecarga de metadados é fixada na criação do sistema de arquivos ou no redimensionamento, não é relatada como espaço 'usado'. Suspeito que isso também ocorra porque os metadados do grupo de cilindros estão em locais fixos no disco e, portanto, são simplesmente implícitos como sendo usados ​​e, portanto, não são marcados ou contabilizados nos mapas de espaço livre.

Mas o reiserfs não pré-aloca nenhum metadado de nenhum tipo. Ele não possui um limite de inodos fixado na criação do sistema de arquivos, porque aloca todos os seus inodes on-the-fly como faz com os blocos de dados. No máximo, ele precisa de algumas estruturas que descrevam o diretório raiz e um mapa de espaço livre de algum tipo. Portanto, usa muito menos espaço quando não tem nada.

Mas isso significa que o reiserfs ocupará mais espaço à medida que você adiciona arquivos, pois alocará metadados (como inodes), bem como o espaço de dados real para o arquivo.

Não sei exatamente como jfs e btrfs controlam o uso do espaço de metadados. Mas suspeito que eles rastreiam isso mais como o reiserfs. O vfat em particular não tem nenhum conceito de inode. Seu mapa de espaço livre (cujo tamanho é fixo na criação do sistema de arquivos (a infame tabela FAT)) armazena grande parte dos dados que um inode armazenaria, e a entrada do diretório (que é alocada dinamicamente) armazena o restante.

Assim como os problemas mencionados pelo Omnifarious, com o ext2 / 3/4, uma certa quantidade de espaço é reservada para raiz - esse espaço reservado não aparece na saída do df.

Por exemplo, criando um pequeno sistema de arquivos (~ 100mb) com opções padrão, usando ext2 em vez de 3 ou 4 para ignorar o espaço que seria ocupado pelo diário:

swann:/tmp# dd if=/dev/zero of=./loop.fs bs=10240 count=10240
swann:/tmp# mkfs.ext2 loop.fs
swann:/tmp# mkdir loop
swann:/tmp# mount -text2 -oloop loop.fs loop
swann:/tmp# df loop
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/loop.fs             99150      1550     92480   2% /tmp/loop

Ajustando a opção de blocos reservados ( tune2fsa -mopção de define os blocos reservados como uma porcentagem e a -ropção define os blocos reservados como um número direto de blocos):

swann:/tmp# umount loop
swann:/tmp# tune2fs -m 25 loop.fs
swann:/tmp# mount -text2 -oloop loop.fs loop
swann:/tmp# df loop
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/loop.fs             99150      1550     72000   3% /tmp/loop

swann:/tmp# umount loop
swann:/tmp# tune2fs -m 0 loop.fs
swann:/tmp# mount -text2 -oloop loop.fs loop
swann:/tmp# df loop
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/loop.fs             99150      1550     97600   2% /tmp/loop

Como você pode ver no exemplo acima, mesmo quando logado como root df, não mostra o espaço reservado na contagem "Disponível". O espaço reservado também não aparece na contagem "Usado", seja logado como root ou como um usuário menos privilegiado. Às vezes, isso pode causar confusão quando um sistema de arquivos está quase cheio, se você não espera esses dois fatos.

Observe também que tune2fs, apesar do nome, é relevante para os sistemas de arquivos ext3 e ext4, bem como para os sistemas ext2.

Sobre a diferença entre sistemas de arquivos, diferentes sistemas de arquivos organizam os blocos de maneira diferente e precisam de mais ou menos dados para identificar e acompanhar os blocos. O tamanho do bloco também faz a diferença, como se você tivesse mais ou menos blocos no mesmo espaço, mais ou menos espaço "perdido". Além disso, os sistemas de arquivos agrupam blocos para evitar a fragmentação de arquivos e cada cluster de blocos possui um identificador de algum tamanho; portanto, mais ou menos clusters de blocos usarão espaço físico diferente no disco. Portanto, a diferença está em como o sistema de arquivos organiza o espaço físico.

Aqui está uma descrição para ext2 e você provavelmente pode encontrar algo semelhante para o reiserfs, mas nunca o usei, então não tenho nenhum.