Qual é a diferença entre “tamanho do inode” e “Bytes por inode”

Question

Abaixo da informação é tirada da página man, eu gostaria de saber a diferença entre bytes por inode e tamanho de Inode?

-i bytes-per-inode

Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value generally shouldn't be smaller than the blocksize of the filesystem, since then too many inodes will be made.Be warned that is not possible to expand the number of inodes on a filesystem after it is created, so be careful deciding the correct value for this parameter.

-I inode-size

Specify the size of each inode in bytes.mke2fs creates 256-byte inodes by default. In kernels after 2.6.10 and some earlier vendor kernels it is possible to utilize inodes larger than 128 bytes to store extended attributes for improved performance.The inode-size value must be a power of 2 larger or equal to 128.The larger the inode-size the more space the inode table will consume, and this reduces the usable space in the filesystem and can also negatively impact performance.Extended attributes stored in large inodes are not visible with older kernels, and such filesystems will not be mountable with 2.4 kernels at all.It is not possible to change this value after the filesystem is created.

    

Answer 1

Bem, primeiro, o que é um inode? No mundo Unix, um inode é um tipo de entrada de arquivo. Um nome de arquivo em um diretório é apenas um rótulo (um link!) Para um inode. Um inode pode ser referenciado em vários locais (hardlinks!).

-i bytes-por-inode (também conhecido como inode_ratio)

Por alguma razão desconhecida, este parâmetro é por vezes documentado como bytes-por-inode e em algum momento como inode_ratio . De acordo com a documentação, esta é a relação bytes / inode . A maioria dos humanos terá uma melhor compreensão quando declarada como (desculpem meu inglês):

• 1 inode para cada X bytes de armazenamento (onde X é bytes por inodo).
• menor tamanho médio de arquivo que você pode ajustar.

A fórmula (retirada do código-fonte mke2fs ):

inode_count = (blocks_count * blocksize) / inode_ratio

Ou mesmo simplificado (supondo que "tamanho da partição" seja aproximadamente equivalente a blocks_count * blocksize , eu não verifiquei a alocação):

inode_count = (partition_size_in_bytes) / inode_ratio

Nota 1: Mesmo que você forneça um número fixo de inode na hora de criação do FS ( mkfs -N ... ), o valor é convertido em uma proporção, para que você possa ajustar mais inode conforme estende o tamanho do sistema de arquivos. p>

Nota 2: Se você ajustar esta proporção, certifique-se de alocar significativamente mais inode do que o que você planeja usar ... você realmente não quer reformatar seu sistema de arquivos.

-I inode-size

Este é o número de bytes que o sistema de arquivos irá alocar / reservar para cada inode que o sistema de arquivos possa ter. O espaço é usado para armazenar os atributos do inode (leia Introdução aos Inodes ). No Ext3, o tamanho padrão era 128. No Ext4, o tamanho padrão é 256 (para armazenar extra_isize e fornecer espaço para atributos estendidos embutidos). leia Linux: Por que mudar o tamanho do inode?

Nota: X bytes de disjkspace são alocados para cada inode alocado, seja livre ou usado, onde X = tamanho do inode.

    

Answer 2

bytes-por-inode determina quantos inodes são criados para esse sistema de arquivos; inode-size determina o tamanho de cada um desses inode.

Você precisa de muitos inodes se você pretende colocar lotes de arquivos pequenos (& / ou muitos diretórios) no arquivo.

AFAIK, você realmente precisa apenas de inodes maiores que o tamanho padrão de 256 bytes se quiser armazenar atributos estendidos para seus arquivos.

    

Answer 3

Esquema de sistema de arquivos extremamente difícil:

|_|__inodes__|_______________________DATA_________________________________|

• inode-ratio / bytes-por-inode = quantidade de inodes para a área DATA
• inode-size = tamanho de cada inode na área inodes

Answer 4

Eu realmente gostei da resposta dos sjas, isso dá a essência da diferença.

Esta é apenas a minha própria expansão (como não posso comentar ou votar, apenas começando com este stackexchange) e eu queria uma resposta para mim declarada de forma equilibrada em termos não técnicos compreensíveis para o usuário que precisa tomar a decisão durante a configuração do volume de dados, mas não necessariamente conhece todos os detalhes por trás da implementação.

Personas / Objetos:  - volume (s) de dados em dispositivos de armazenamento  - arquivos em volume (s)  - dispositivos de armazenamento, eles são formatados e fornecem blocos de bytes e seus endereços  - locais de arquivos no armazenamento

Ações: criação / exclusão / renomeação de arquivos e pastas pelo sistema operacional no armazenamento, leituras / gravações / movimentações de arquivos, alterações de permissões, etc.

O arquivo de tamanho de N bytes precisa ser criado em "pedaços" (blocos). Embora teoricamente se possa pensar que os arquivos podem ser gerenciados como seqüências de bytes simples (logicamente eles podem) tudo o que precisaríamos para gerenciar arquivos no espaço seria um índice designado informando algumas propriedades do arquivo (nome etc) e onde cada arquivo inicia o armazenamento. No entanto, devido à maneira como o hardware é projetado com os "barramentos" e "blocos" e considerações de desempenho, esses "blocos" são de tamanho específico e um múltiplo do tamanho de bloco da mídia (por exemplo, 512 bytes, 4096 bytes) e são gerenciado pela camada inodes, que informa a próxima camada sobre os locais dos arquivos e como os fragmentos são agrupados quando precisam ser encontrados, carregados na memória, etc.

Se alguém tiver um grande rolo de papel (volume) e tiver que projetar um armazenamento de informações para documentos feitos de páginas (de caracteres ou bits de informação) para armazenar documentos de várias páginas, o que é necessário é um índice (para localizar documentos), espaço de armazenamento para as páginas (com algumas posições simples de páginas). No mecanismo de agrupamento Unix (inodes) e corte real em páginas. inode-size é o tamanho da entrada do índice (mais ou menos) bytes por inode é o tamanho da página

Efeitos da alteração das duas configurações em questão:

mudando o tamanho do inode - geralmente não há necessidade de mudar, fique com o padrão (conforme link postado na resposta anterior para uma discussão)

bytes-por-inode - afeta o número máximo de arquivos que podem ser criados no volume (possivelmente desempenho e "desperdício" de bytes não utilizados)

Voltando à analogia do rolo de papel: Imagine ter que escrever e armazenar um documento de tamanho específico (um arquivo) em tal sistema (ou muitos documentos de vários tamanhos) - se o tamanho da página, que é predefinido durante a definição "sistema de gravação e armazenamento" e não flexível, for o mesmo documento pode exigir muitas páginas, se o tamanho da página do "sistema" for muito grande e o tamanho do documento for pequeno, então um monte de papel poderia ser desperdiçado tendo espaços em branco e ajustando pequenos arquivos em uma página. Se o tamanho da página for grande - há menos páginas que precisam ser usadas para o documento, mas pode haver muito "espaço em branco desperdiçado" na última página usada. Então tudo depende ... do tamanho dos arquivos que serão usados e quantos. A outra consideração é a velocidade de encontrar e trazer o documento de muitas páginas.

Espero que faça sentido (para mim) e por favor, comente se eu tiver abusado seriamente de qualquer parte das opções de design ext ou mkfs.