EXT4 para arquivos muito grandes (> 1 GB): aumentar o tamanho do bloco, usar clusters de blocos ou ambos?

O próprio documento que você vinculou diz (ênfase minha):

No momento, o tamanho padrão de um bloco é 4KiB, que é um tamanho de página comumente suportado na maioria dos hardwares compatíveis com MMU. Isso é uma sorte, pois o código ext4 não está preparado para lidar com o caso em que o tamanho do bloco excede o tamanho da página .

Das arquiteturas de processador conhecidas capazes de rodar Linux, apenas ARM, Alpha AXP, Itanium ou PowerPC têm/tiveram a capacidade de usar tamanhos de página além dos habituais 4 KiB.

Embora os processadores AMD64/x86_64 possam usar páginas enormes, isso não é exatamente a mesma coisa - o tamanho básico da página do sistema ainda é de 4 KiB, páginas enormes apenas permitem atribuí-las em pacotes maiores para melhorar a eficiência do gerenciamento de memória em sistemas com memória grande. Isso não altera o requisito fundamental "tamanho do bloco ext4 <= tamanho da página da memória do sistema".

Com processadores PowerPC ou ARM de 64 bits, o tamanho da página (o "tamanho do bloco" básico do gerenciamento de memória do sistema) pode ser aumentado em até 64 KiB, o que permite que o sistema de arquivos ext4 também aumente suas operações internas. No AMD64/x86_64, essa opção não está disponível, portanto, os clusters de blocos seriam a única maneira disponível de reduzir o espaço e o trabalho necessários para os metadados do sistema de arquivos.

Usei um sistema que tinha um sistema de arquivos ext4 estendido para> 10 TB e executar uma verificação do sistema de arquivos não foi uma experiência agradável. É verdade que era um sistema antigo cujos sistemas de arquivos foram expandidos e reexpandidos sem nenhum ajuste cuidadoso, muito além dos limites da capacidade original projetada do sistema. (Também era um servidor de vídeo.)

Mas com base nisso, eu diria que o ext4 definitivamente precisa de ajustes específicos para lidar com sucesso com sistemas de arquivos de dezenas de terabytes. Como Romeo Ninov nos comentários, recomendo que você reconsidere outros tipos de sistemas de arquivos, se possível: embora o ext4 possa ser usado com sistemas de arquivos muito maiores que 10 TB, acho que poucas dezenas de terabytes são o limite atual do que geralmente é prático fazer com isso.

No entanto, se você essencialmente escrever o conteúdo do sistema de arquivos uma vez e depois mantê-lo somente leitura, quase nunca precisará executar uma verificação do sistema de arquivos nele, o que evitará um problema significativo.

Ext4 pode lidar razoavelmente bem com arquivos de até 16TiB e sistemas de arquivos de até 1PiB e é usado regularmente nesses tamanhos em alguns dos maiores sistemas de arquivos paralelos do mundo (consulte https://en.wikipedia.org/wiki/Lustre_(file_system) para detalhes). Não deve haver problemas com arquivos de 1GiB e um HDD de 12 TiB.

Eu tenho algumas unidades de 10 TiB em meu servidor de arquivos doméstico com ext4. As opções padrão do mke2fs que habilitam extensões e outros recursos devem fornecer bom desempenho.

Quanto à largefileopção, isso é razoável se você souber que a maioria dos arquivos será muito grande. No entanto, a economia geral de espaço não é enorme e pode não valer a pena. Acabei usando meu servidor de mídia também para backups, e isso criou uma tonelada de arquivos pequenos.

Expandindo a resposta da TelcoM... se você quiser usar um tamanho de bloco diferente de 4Kb em x86[-64] então você precisará recompilar o kernel. Esta costumava ser a única maneira de suportar grandes sistemas de arquivos com kernels de 32 bits. Mas então veio o suporte a arquivos grandes e inodes de 64 bits. E hoje em dia (a menos que você ainda esteja rodando em 32 bits), você nem precisa dizer ao mount/fstab que um sistema de arquivos usa 64 bits. Mas ainda há muitas informações desatualizadas na internet (por exemplo, a documentação ATUAL do aws - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html ).

Os clusters de blocos no ext4 forneceram uma solução alternativa para inodes de 32 bits/tamanho de bloco de 4k.

Mas isso não é mais relevante - inodes de 32 bits + tamanhos de bloco de 4K limitam o tamanho total de um dispositivo de bloco a 16 TB e você só tem 12.

Existem razões para usar blocos de tamanhos diferentes (ou clusters de blocos). IIRC, tanto Oracle quanto MySQL usam um tamanho de bloco de 8k internamente - e combinar isso no sistema de arquivos proporciona um aumento significativo no rendimento.

Então... não, você não precisa fazer nada inteligente (além de usar GPT em vez de MBR se estiver particionando).