máximo de arquivos por diretório no ext4

Gerencio um aplicativo que contém um armazenamento de arquivos no qual todos os arquivos são armazenados com os nomes de arquivos iguais às somas md5. Todos os arquivos são armazenados em um diretório. Atualmente, existem milhares, mas em breve devem haver milhões de arquivos no servidor. O servidor atual está executando o Ubuntu 11.10 em um sistema de arquivos ext4.

Alguém me disse que não é aconselhável colocar muitos arquivos em um diretório, pois isso criará um aumento significativo no tempo e na confiabilidade da pesquisa (ele tinha uma história sobre o máximo de arquivos que um único diretório poderia apontar, resultando em uma grande lista vinculada). Em vez disso, ele sugeriu criar subdiretórios com, por exemplo, substrings do nome do arquivo. No entanto, isso tornará algumas coisas no meu aplicativo muito mais complicadas.

Isso ainda é verdade ou os sistemas de arquivos modernos (por exemplo, ext4) têm maneiras mais eficientes de lidar com isso e escalar naturalmente? A Wikipedia tem alguns detalhes sobre os sistemas de arquivos, mas na verdade não diz nada sobre o máximo de arquivos por diretório ou tempos de pesquisa.

Os ext3sistemas de arquivos e posteriores suportam indexação de diretório em árvore B com hash . Isso é muito bom, desde que as únicas operações que você faça sejam adicionar, excluir e acessar pelo nome. No entanto, eu ainda recomendaria quebrar os diretórios. Caso contrário, você cria uma armadilha perigosa para obter ferramentas ( updatedb, ls, due assim por diante) que executam outras operações em diretórios que podem explodir se o diretório tem muitas entradas.

O principal do problema é pesquisar no inode do diretório o arquivo que você deseja. Alguns sistemas de arquivos fazem isso melhor do que outros. Alguns escalam perto dos bilhões, mas se você tiver apenas ... 20K arquivos chegando a esses arquivos é notavelmente mais rápido. Além disso, contagens grandes de arquivos criam problemas para certas ferramentas e, como resultado, podem tornar o backup / restauração um problema muito mais difícil.

Por acaso, encontrei exatamente o mesmo problema em nosso próprio desenvolvimento (md5sum como nome do arquivo, dimensionamento). O que eu recomendei aos nossos desenvolvedores é cortar a corda em pedaços. Eles foram com grupos de 4, mas no sistema de arquivos em que estávamos na época, muitos deles se mostrariam problemáticos do ponto de vista de desempenho, então acabaram se dividindo em um grupo de 3 pelos 6 primeiros trigêmeos e deixando o resto como o nome do arquivo no diretório do terminal.

Grupo de 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Grupo de 3:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Isso tem a vantagem de manter os tamanhos dos diretórios pequenos e, como o MD5sum é bastante aleatório, ele cria árvores de diretórios balanceadas. É improvável que esse último diretório obtenha mais do que alguns arquivos. E não foi tão difícil trabalhar com nosso código. Trabalhamos com vários milhões de projetos de arquivos, então o dimensionamento foi muito importante para nós.

Os sistemas de arquivos modernos lidam com diretórios muito grandes muito bem, até milhões de arquivos. Mas ferramentas convencionais não. Por exemplo, listar um diretório tão grande com "ls" levaria muito tempo, pois normalmente leria o diretório inteiro e o classificava (embora você possa usar ls -f para evitar a classificação). Não começaria a exibir arquivos até que todos sejam lidos. Dividir os nomes ajuda em alguns casos, mas não em todos (por exemplo, a replicação rsync ainda pode precisar coletar a árvore inteira de nomes).

Posso sugerir o uso de um banco de dados SQL? Isso provavelmente transformaria essa fraqueza percebida em seu aplicativo em uma força.