O tamanho do bloco é uma espécie de artefato dos velhos tempos dos sistemas de arquivos, onde a memória e o armazenamento eram bens preciosos, de modo que mesmo os indicadores dos dados precisavam ser otimizados para o tamanho. O MS-DOS usava ponteiros de 12 bits para as primeiras versões do FAT, permitindo o gerenciamento de até 2 ^ 12 = 4096 blocos (ou arquivos). Como o tamanho máximo do sistema de arquivos é inerentemente restrito a (max_block_size) x (max_block_number) , o tamanho do bloco "direito" foi um problema em que você teve que pensar no tamanho total do sistema de arquivos e na quantidade de espaço que você indo para o lixo, escolhendo um tamanho de bloco maior.
Como sistemas de arquivos modernos usariam ponteiros de 48 bits (ext4), 64 bits (NTFS, BTRFS) ou até 128 bits (ZFS), permitindo sistemas de arquivos enormes (em termos de números de blocos), escolhendo um bloco O tamanho tornou-se um problema menos importante, a menos que você tenha um aplicativo específico e deseje otimizá-lo. Exemplos podem ser
- bloqueia dispositivos com blocos grandes nos quais você não deseja que arquivos diferentes "compartilhem" um único bloco físico como uma otimização de desempenho - os grandes bloqueios do sistema de arquivos correspondentes ao tamanho do bloco do dispositivo físico são escolhidos neste caso
- software de registro que gravaria um grande número de arquivos com um tamanho fixo no qual você deseja otimizar a utilização do armazenamento, escolhendo o tamanho do bloco para corresponder ao tamanho de arquivo típico
Como você pediu especificamente para ext2 / 3 - agora esses são sistemas de arquivos antigos usando ponteiros de 32 bits, portanto, com dispositivos grandes, é possível executar o mesmo "tamanho máximo do sistema de arquivos vs. espaço desperdiça " considerações sobre as quais escrevi anteriormente.
O desempenho do sistema de arquivos pode sofrer de um grande número de blocos usados para um único arquivo, portanto, um tamanho de bloco maior pode fazer sentido. Especificamente, o ext2 tem um número bastante limitado de referências de bloco que podem ser armazenadas diretamente com um inode e um arquivo que consome um grande número de blocos tem que ser referenciada através de quatro camadas de listas ligadas :
Então, obviamente, um arquivo com menos blocos exigiria menos camadas de referência e, portanto, permitiria, teoricamente, acesso mais rápido. Dito isto, o cache inteligente provavelmente encobrirá a maior parte dos aspectos de desempenho deste problema na prática.
Outro argumento frequentemente usado em favor de blocos maiores é fragmentação . Se você tiver arquivos que estão crescendo continuamente (como logs ou bancos de dados), ter tamanhos de bloco de sistema de arquivos pequenos levaria a mais fragmentação de dados no disco, reduzindo as chances de que grandes blocos de dados fossem lidos sequencialmente. Embora isso seja inerentemente verdadeiro, você deve sempre lembrar que em um subsistema de E / S que atende a vários processos (bandejas / usuários), o acesso a dados sequenciais é altamente improvável para aplicativos de uso geral. Ainda mais se você virtualizou seu armazenamento. Portanto, a fragmentação em si não seria suficiente como justificativa para uma escolha maior de tamanho de bloco para todos, exceto alguns casos específicos.
Como regra geral que é válida para qualquer implementação sã de FS, você deve deixar o tamanho do bloco como padrão, a menos que tenha uma razão específica para assumir (ou, melhor ainda, mostrar dados de teste) qualquer tipo de se beneficiar da escolha de um tamanho de bloco não padrão.