Relação entre “Block Size” e “Upper Limits” no ext2

Question

Uma pergunta aparentemente similar pergunta o motivo pelo qual o limite superior do arquivo pode ser 2 TB em ext2 . Eu estou tentando entender, mas a documentação sobre ext2 , mas acho isso difícil. Por favor, corrija-me se estiver errado:

• Os blocos podem ter de 1 a 4 KB de tamanho
• quantidade disponível de blocos é baseada em um valor de 32 bits: 2 ³² = 4.294.967.296 blocos

Na documentação que encontrei: 2 ³¹ -1 = 2.147.483.647 Blocos endereçáveis. Tenho saudades de 2.147.483.649 Blocos.

Meu palpite é que isso é "reservado" para o Superblock , os Descritores de grupos de blocos , seus backups etc. (correto?)

Pergunta

Como exatamente os limites de tamanho de arquivo são calculados em ext2

E, com antecedência: é - e em caso afirmativo - até onde isso pode ser traduzido para ext3 e ext4 (ou outros sistemas de arquivos ... por favor?) - Ainda estou longe deles e não sou preguiçoso olhe para mim mesmo; apenas confuso sobre onde o básico vem .

    

Answer 1

A resposta me confunde.

Veja o código-fonte ext2 (é menor que 9K linhas, nada assustador), function ext2_block_to_path .

Aqui, o campo i_block (que significa o número do bloco) é definido como long , o que significa signed long. i_block é verificado como não negativo, configurando o limite em 2 ^ 31 blocos no sistema de arquivos. Veja o comentário:

Portability note: the last comparison (check that we fit into triple
indirect block) is spelled differently, because otherwise on an
architecture with 32-bit longs and 8Kb pages we might get into trouble
if our filesystem had 8Kb blocks. We might use long long, but that would
kill us on x86. Oh, well, at least the sign propagation does not matter -
i_block would have to be negative in the very beginning, so we would not
get there at all.

O que eu não entendo é por que essa função não define i_block como _le32 , que é __u32 unsigned 32-bit integer como em inode definition e alguns outros lugares?

Agora, se você estiver interessado em limitar os tamanhos em esta tabela ,

• blocos do sistema de arquivos são limitados por não-negativos em long type (2 ^ 31)
• blocos por grupo e inodes por grupo, os limites são determinados pelo bitmap de bloco / bitmap do inode. Cada bloco / inodo recebe 1 bit no respectivo mapa de bits do bloco / inode bitmap e o próprio bitmap ocupa um quarteirão inteiro. Então bloco é 1024 bytes, há 1024 bytes * 8bits / byte = 8K blocos por grupo
• bytes por grupo de blocos - blocos por grupo * tamanho de bloco. Para blocos de 1024 bytes, resulta em 8K blocos / grupo * 1024 bytes / bloco = 8 MiB / grupo
• tamanho do sistema de arquivos (Linux) - como mencionado nos comentários, o campo i_blocks inode, representando o número total de blocos no inode, opera estranhamente setores de 512 bytes, não blocos reais.
• blocos por arquivo - determinado por blocos indiretos de três níveis. Com blocos de 1024 bytes, podemos espremer 256 ponteiros = 2 ^ 8 ponteiros em cada bloco, o que resulta em 2 ^ 24 blocos por arquivo = 16 milhões de blocos / arquivo
• tamanho do arquivo - multiplique os blocos por arquivo por tamanho de bloco, o que para blocos de 1024 bytes resulta em arquivos de 16 bilhões de bytes (16 GiB).