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

7

Acabei de notar que qualquer sistema de arquivos ext {2,3,4} que estou tentando criar no disco rígido de 500G não usa todo o espaço disponível (466G). Eu também tentei reiser3, xfs, jfs, btrfs e até mesmo 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 do fs ainda é 459G.

O mesmo é para 1Tb HDD: 932G reiserfs, 917G ext4.

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

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

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

para reiserfs:

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

para o ext4:

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

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

UPD2: Preenchendo volumes com dados reais via dd:

reiserfs:

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

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

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

Desculpe por russo, mas eu corri na localidade padrão e repeti-lo é muito longo. Não importa, a saída dd é óbvia.

Então, acontece que o mke2fs realmente cria um sistema de arquivos menor que o do outro mkfs.

    
por Ineu 15.08.2010 / 19:03

3 respostas

18

Existem dois motivos pelos quais isso é verdade.

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

Essas duas formas diferentes de falar sobre tamanhos frequentemente levam a muita confusão.

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

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

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

Sistemas de arquivos diferentes usam diferentes quantidades de espaço para informações de manutenção e relatam o uso do espaço de maneiras diferentes.

Por exemplo, o ext2 divide o disco em grupos de cilindros. Em seguida, ele pré-aloca espaço em cada grupo de cilindros para inodes e mapas de espaço livre. O ext3 faz a mesma coisa, uma vez que é basicamente o ext2 + journaling. E o ext4 também faz exatamente a mesma coisa, já que é uma modificação bastante direta (e quase incompatível) do ext3. E como essa sobrecarga de meta-dados é fixa na criação do sistema de arquivos ou no redimensionamento, ela não é informada como espaço 'usado'. Eu suspeito que isso também é porque os meta-dados do grupo de cilindros estão em lugares fixos no disco, e assim é simplesmente implícito como sendo usado e, portanto, não marcado ou contabilizado em mapas de espaço livre.

Mas o reiserfs não pré-aloca metadados de qualquer tipo. Ele não tem nenhum limite de inode que seja corrigido na criação do sistema de arquivos porque ele aloca todos os seus inodes imediatamente, como acontece com os blocos de dados. No máximo, precisa de algumas estruturas descrevendo o diretório raiz e um mapa de espaço livre de algum tipo. Por isso, usa muito menos espaço quando não tem nada.

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

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

    
por 15.08.2010 / 19:24
8

Assim como os problemas que o Omnifarious menciona, com ext2 / 3/4 uma certa quantidade de espaço é reservada para o root - este 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 usado pelo periódico:

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 ( tune2fs ' -m ' define os blocos reservados como uma porcentagem, e a opção -r 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 não é exibido na contagem "Usado", esteja logado como usuário root ou menos privilegiado. Isso às vezes pode causar confusão quando um sistema de arquivos está quase cheio, se você não está esperando esses dois fatos.

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

    
por 15.08.2010 / 19:52
0

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

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

    
por 15.08.2010 / 23:53

Tags