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.
Esquema de sistema de arquivos extremamente difícil:
fonte
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.
fonte