Estamos criando um produto com grande probabilidade de gerar volumes XFS muito grandes, e estou tentando descobrir os gargalos de dimensionamento com maior probabilidade de execução, considerando a arquitetura.
Conforme manipulamos os arquivos, eles são colocados em diretórios nos volumes XFS. Devido ao número de arquivos que manipulamos, a contagem de arquivos está na casa das dezenas de milhões e provavelmente chegará às centenas de milhões antes do lançamento. Sabemos disso porque nosso produto atual se comporta dessa maneira, por isso é razoável esperar que o nosso próximo faça da mesma forma.
Portanto, a engenharia correta correta está em ordem.
Esta semana, os arquivos são baseados no seguinte layout aproximado:
$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file
O que dá diretórios parecidos com:
0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file
A razão para chunking o md5sum é evitar o problema "grande pilha de arquivos / diretórios em um diretório". Devido ao md5sum chunking, significa que 1 arquivo faz com que 8 diretórios sejam criados. Isso tem impactos inode bem claros, mas não estou claro quais serão esses impactos para o XFS quando chegarmos à escala.
Quais são os impactos?
Isto é com o kernel 2.6.32, a propósito, o CentOS 6.2 no momento (isso pode mudar se necessário).
Em testes, criei o volume xfs com padrões e não estou usando nenhuma opção de montagem. Isso é para acabar com os problemas cedo. noatime é algo óbvio, já que não precisamos disso. O ajuste geral do XFS é outro problema que preciso resolver, mas agora estou preocupado com o efeito multiplicador de metadados que criamos agora.
Eu já sei qual será a melhor solução, só não sei se tenho um caso para pressionar pela mudança.
Como os md5sums são significativamente únicos nos primeiros dígitos, e os subprojetos individuais raramente excedem 5 milhões de arquivos, parece-me que precisamos apenas dos dois primeiros blocos. O que daria layouts como:
0123456/001/0e15/a644/897219acb4b597f651d69a4d/file
Um primeiro e segundo níveis completamente completos teriam 2 diretórios de primeiro nível 16 e 2 diretórios de segundo nível 16 em cada diretório de primeiro nível, para um total de 2 32 diretórios no volume.
O subprojeto hipotético de 5 milhões de arquivos teria, portanto, 2 diretórios de primeiro nível, aproximadamente 76 diretórios de segundo nível em cada e um ou dois diretórios de terceiro nível em cada um. diretório de segundo nível.
Esse layout é muito mais eficiente para metadados. Eu só não sei se vale a pena o esforço para mudar como as coisas estão indo agora.