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


18

Abaixo as informações são retiradas da página de manual, gostaria de saber a diferença entre bytes por inode e tamanho do inode?

-i bytes-per-inode

Especifique a proporção de bytes / inode. O mke2fs cria um inode para todos os bytes de bytes por espaço do disco. Quanto maior a taxa de bytes por inode, menos inodes serão criados. Esse valor geralmente não deve ser menor que o tamanho do bloco do sistema de arquivos, pois muitos inodes serão criados. Esteja ciente de que não é possível expandir o número de inodes em um sistema de arquivos após a criação, portanto, tenha cuidado ao decidir o correto valor para este parâmetro.

-I inode-size

Especifique o tamanho de cada inode em bytes.mke2fs, por padrão, para criar inodes de 256 bytes. Em kernels após 2.6.10 e alguns kernels de fornecedores anteriores, é possível utilizar inodes maiores que 128 bytes para armazenar atributos estendidos para melhorar o desempenho. O valor do tamanho do inode deve ser uma potência de 2 maior ou igual a 128. -tamanho quanto mais espaço a tabela de inodes consumir, e isso reduz o espaço utilizável no sistema de arquivos e também pode afetar negativamente o desempenho. Atributos estendidos armazenados em inodes grandes não são visíveis em kernels mais antigos e esses sistemas de arquivos não podem ser montados com kernels 2.4 Não é possível alterar esse valor após a criação do sistema de arquivos.

Respostas:


13

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, esse parâmetro é documentado em algum momento como bytes por inode e em algum momento como inode_ratio . De acordo com a documentação, essa é a proporção de bytes / inode . A maioria dos humanos terá uma melhor compreensão quando declarada como (desculpe meu inglês):

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

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

inode_count = (blocks_count * blocksize) / inode_ratio

Ou até 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 se você fornecer um número fixo de inode no momento da criação do FS ( mkfs -N ...), o valor será convertido em uma proporção, para que você possa ajustar mais inode à medida que aumenta o tamanho do sistema de arquivos.

Nota 2: Se você ajustar essa taxa, aloque significativamente mais inode do que planeja usar ... você realmente não deseja reformatar seu sistema de arquivos.

-I tamanho do inode

Este é o número de bytes que o sistema de arquivos alocará / reserva 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_isizee fornecer espaço para atributos estendidos embutidos). leia Linux: Por que alterar o tamanho do inode?

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


5

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

Você precisa de muitos inodes se pretende colocar muitos arquivos pequenos (e / ou muitos diretórios) no sistema de arquivos.

AFAIK, você realmente só precisa de inodes maiores que o tamanho padrão de 256 bytes para armazenar atributos estendidos para seus arquivos. psusi diz nos comentários que isso não está correto.


4
Na verdade, os atributos estendidos são armazenados em seu próprio bloco, e não no inode, portanto, você não precisa de um inode maior para eles. Houve alguns patches flutuando nas listas de discussão recentemente para finalmente adicionar a capacidade de armazenar atributos estendidos no inode se eles forem pequenos o suficiente para caber, mas se eles atingissem a linha principal ainda, isso teria sido muito recentemente.
Psusi

1

Esquema de sistema de arquivos extremamente difícil:

|_|__inodes__|_______________________DATA_________________________________|
  • proporção de inode / bytes por inode = quantidade de inodes para a área DATA
  • inode-size = tamanho de cada inode na área de inodes

0

Gostei muito da resposta do sjas, dá a essência da diferença.

Essa é apenas minha própria expansão (como não posso comentar ou votar, apenas começando com essa troca de pilha) e queria uma resposta para mim, declarada de maneira equilibrada em termos não técnicos, compreensíveis para o usuário que precisa tomar a decisão durante o volume de dados configuração, mas não necessariamente conheça 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 - localizações dos arquivos no armazenamento

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

O arquivo com tamanho de N bytes precisa ser criado em "pedaços" (blocos). Embora teoricamente se possa pensar que os arquivos possam ser gerenciados como seqüências de bytes únicos (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 as 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 de inodes, que informa a próxima camada sobre a localização dos arquivos e como os blocos são agrupados quando precisam ser encontrados, carregados na memória etc.

Se alguém tivesse um grande rolo de papel (volume) e tivesse que projetar um armazenamento de informações para documentos feitos de páginas (de caracteres ou bits de informações) para armazenar documentos de várias páginas, é necessário um índice (para encontrar documentos), espaço de armazenamento para as páginas (com algumas posições simples das 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:

changin inode-size - geralmente não há necessidade de alterar, mantenha o padrão (conforme o link postado na resposta anterior a uma discussão)

bytes por inode - afeta o número máximo de arquivos que se pode criar 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 um sistema desse tipo (ou muitos documentos de vários tamanhos) - se o tamanho da página, que é apresentado durante o "sistema de gravação e armazenamento "definição e não flexível, é o mesmo documento que pode exigir muitas páginas, se o tamanho da página do" sistema "for muito grande e o tamanho do documento for pequeno, muito papel poderá ser desperdiçado com espaços em branco e encaixe de arquivos pequenos 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 de quantos. A outra consideração é a velocidade de encontrar e trazer o documento de muitas páginas.

Espero que faça sentido (faz para mim) e comente se eu abusei seriamente de qualquer parte das opções ext design ou mkfs.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.