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.