Por que 67108864 é a razão máxima de bytes por inodo? Por que há um max?

Question

Formatando um disco para arquivos de vídeo puramente grandes, calculei o que achei ser um valor apropriado de bytes por inode, para maximizar o espaço em disco utilizável.

Fui recebido, no entanto, com:

mkfs.ext4: invalid inode ratio [RATIO] (min 1024/max 67108864)

Eu assumo que o mínimo é derivado do que poderia teoricamente ser usado - não adianta ter mais inodes do que jamais poderia ser utilizado.

Mas de onde vem o máximo? mkfs não sabe o tamanho dos arquivos que eu vou colocar no sistema de arquivos que ele cria - então a menos que seja {disk size} - {1 inode size} eu não entendo porque nós temos um máximo, muito menos um tão baixo quanto 67MB .

    

Answer 1

Por causa da maneira como o sistema de arquivos é construído. É um pouco confuso e, por padrão, você não pode ter a proporção de até 1/64 MB.

Do documento Ext4 Disk Layout no kernel.org , vemos que os componentes internos do sistema de arquivos são vinculado ao tamanho do bloco (4 kB por padrão), que controla o tamanho de um grupo de blocos e a quantidade de inodes em um grupo de blocos. Um grupo de blocos possui um bitmap de um bloco dos blocos do grupo e um mínimo de um bloco de inodes.

Por causa do bitmap, o tamanho máximo do grupo de blocos é 8 blocks * block size in bytes , portanto, em um FS com blocos de 4 kB, os grupos de blocos são 32768 blocos ou 128 MB de tamanho. Os inodes recebem um bloco no mínimo, portanto, para blocos de 4 kB, você recebe pelo menos (4096 B/block) / (256 B/inode) = 16 inodes/block ou 16 inodes por 128 MB ou 1 inode por 8 MB.

A 256 B / inode, isto é 256 B / 8 MB, ou 1 byte por 32 kB, ou cerca de 0,003% do tamanho total, para os inodes.

Diminuir o número de inodes não ajudaria, você só teria um bloco de inodes parcialmente preenchido. Além disso, o tamanho de um inode também não importa, pois a alocação é feita por bloco. É o tamanho do grupo de blocos que é o limite real para os metadados.

Aumentar o tamanho do bloco ajudaria e, em teoria, o tamanho máximo do grupo de blocos aumenta no quadrado do tamanho do bloco (exceto que ele parece limitar um pouco menos que 64k blocos / grupo). Mas você não pode usar um tamanho de bloco maior que o tamanho da página do sistema, assim, no x86, você fica preso em blocos de 4 kB.

No entanto, existe o bigalloc feature que é exatamente o que você deseja:

for a filesystem of mostly huge files, it is desirable to be able to allocate disk blocks in units of multiple blocks to reduce both fragmentation and metadata overhead. The bigalloc feature provides exactly this ability.

The administrator can set a block cluster size at mkfs time (which is stored in the s_log_cluster_size field in the superblock); from then on, the block bitmaps track clusters, not individual blocks. This means that block groups can be several gigabytes in size (instead of just 128MiB); however, the minimum allocation unit becomes a cluster, not a block, even for directories.

Você pode ativar isso com mkfs.ext4 -Obigalloc e definir o tamanho do cluster com -C<bytes> , mas mkfs observa que:

Warning: the bigalloc feature is still under development
See https://ext4.wiki.kernel.org/index.php/Bigalloc for more information

Há menções de problemas em combinação com a alocação atrasada nessa página e o ext4 man página , e as palavras "risco enorme" também aparecem na página wiki do Bigalloc.

Nada disso tem nada a ver com o limite de 64 MB / inode definido pela opção -i . Parece ser apenas um limite arbitrário definido no nível da interface. O número de inodes também pode ser definido diretamente com a opção -N e, quando usado, não há verificações. Além disso, o limite superior baseia-se no máximo tamanho do bloco do sistema de arquivos, não o tamanho do bloco escolhido de fato como os limites estruturais são.

Por causa do limite de 64k blocos / grupo, sem bigalloc não há como obter tão poucos inodes quanto a proporção de 64 MB / inode implicaria, e com bigalloc , o número de inodes pode ser muito menor do que isso.

    

Answer 2

O número que você vê é codificado, pelas razões abaixo.

O código-fonte mke2fs tem:

            com_err(program_name, 0,
                _("invalid inode ratio %s (min %d/max %d)"),
                optarg, EXT2_MIN_BLOCK_SIZE,
                EXT2_MAX_BLOCK_SIZE * 1024);

(existe até uma mensagem nas notas de lançamento sobre ser mais gentil com o usuário e mostrar o valor mínimo e máximo possível quando um erro é lançado, o que é melhor do que antes).

E também:

#define EXT2_MIN_BLOCK_SIZE (1 << EXT2_MIN_BLOCK_LOG_SIZE)
#define EXT2_MAX_BLOCK_SIZE (1 << EXT2_MAX_BLOCK_LOG_SIZE)

E finalmente:

define EXT2_MIN_BLOCK_LOG_SIZE      10  /* 1024 */
define EXT2_MAX_BLOCK_LOG_SIZE      16  /* 65536 */

Então, isso explica o que você vê.

Eu teria me esperado, por link , que a proporção seria no máximo o tamanho máximo da partição dividido pela contagem máxima de inode, mas não é.

Por suas especificações, para ext4 o tamanho máximo do volume é 1 exbibyte (2 ⁶⁰ bytes), o número máximo de inodes é 2 ³² e o máximo o tamanho do arquivo é 16 TiB (16 * 2 ⁴⁰ = 2 ⁴⁴ ) para blocos de 4k.

Assim, o tamanho máximo da partição dividido pela contagem de inodes seria 2 ^60-32 = 2 ²⁸ , que não é o que é codificado no arquivo de origem (67108864 é 2 ²⁶ ). Eu não tenho idéia da diferença, mas também não sou desenvolvedor de sistemas de arquivos.