Sistema de arquivos grande número de arquivos em um único diretório

OK, não é tão grande, mas preciso usar algo em que cerca de 60.000 arquivos com tamanho médio de 30kb sejam armazenados em um único diretório (este é um requisito, portanto, não é possível simplesmente invadir subdiretórios com um número menor de arquivos).

Os arquivos serão acessados ​​aleatoriamente, mas uma vez criados, não haverá gravações no mesmo sistema de arquivos. Atualmente, estou usando o Ext3, mas acho muito lento. Alguma sugestão?

Você deve considerar o XFS. Ele suporta um número muito grande de arquivos, tanto no sistema de arquivos quanto no diretório, e o desempenho permanece relativamente consistente, mesmo com um grande número de entradas devido às estruturas de dados da árvore B +.

Há uma página em seu wiki para um grande número de artigos e publicações que detalham o design. Eu recomendo que você tente e faça uma comparação com a sua solução atual.

Um bilhão de arquivos no Linux

O autor deste artigo analisa alguns dos problemas de desempenho em sistemas de arquivos com grandes contagens de arquivos e faz algumas boas comparações do desempenho de vários sistemas de arquivos ext3, ext4 e XFS. Isso é disponibilizado como uma apresentação de slides. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

Muitos arquivos em um diretório no ext3 foram discutidos em detalhes no site irmão stackoverflow.com

Na minha opinião, 60.000 arquivos em um diretório no ext3 estão longe do ideal, mas dependendo dos outros requisitos, pode ser bom o suficiente.

ESTÁ BEM. Fiz alguns testes preliminares usando ReiserFS, XFS, JFS, Ext3 (dir_hash ativado) e Ext4dev (kernel 2.6.26). Minha primeira impressão foi que todas eram rápidas o suficiente (na minha estação de trabalho robusta) - acontece que a máquina de produção remota tem um processador bastante lento.

Eu experimentei alguma estranheza com o ReiserFS, mesmo nos testes iniciais, o que descartou isso. Parece que o JFS possui 33% menos requisitos de CPU que todos os outros e, portanto, testará isso no servidor remoto. Se funcionar bem o suficiente, eu usarei isso.

Estou escrevendo um aplicativo que também armazena muitos arquivos, embora os meus sejam maiores e eu tenho 10 milhões deles que estarei dividindo em vários diretórios.

ext3 é lento principalmente devido à implementação padrão da "lista vinculada". Portanto, se você tiver muitos arquivos em um diretório, isso significa que abrir ou criar outro ficará cada vez mais lento. Existe algo chamado índice htree que está disponível para o ext3 que supostamente melhora bastante as coisas. Mas, está disponível apenas na criação do sistema de arquivos. Veja aqui: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Como você precisará reconstruir o sistema de arquivos de qualquer maneira e devido às limitações do ext3, minha recomendação é que você use o ext4 (ou XFS). Eu acho que o ext4 é um pouco mais rápido com arquivos menores e tem recriações mais rápidas. Índice Htree é padrão no ext4, tanto quanto eu sei. Eu realmente não tenho nenhuma experiência com JFS ou Reiser, mas já ouvi pessoas recomendando isso antes.

Na realidade, eu provavelmente testaria vários sistemas de arquivos. Por que não tentar ext4, xfs & jfs e ver qual deles oferece o melhor desempenho geral?

Algo que um desenvolvedor me disse que pode acelerar as coisas no código do aplicativo não é fazer uma chamada "stat + open", mas sim "open + fstat". O primeiro é significativamente mais lento que o segundo. Não tenho certeza se você tem algum controle ou influência sobre isso.

Veja meu post aqui no stackoverflow. Armazenando e acessando até 10 milhões de arquivos no Linux, existem algumas respostas e links úteis.

Usar o tune2fs para ativar o dir_index pode ajudar. Para ver se está ativado:

sudo tune2fs -l /dev/sda1 | grep dir_index

Se não estiver ativado:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

Mas tenho a sensação de que você pode estar seguindo o caminho errado ... por que não gerar um índice plano e usar algum código para selecionar aleatoriamente com base nisso. Você pode usar subdiretórios para uma estrutura em árvore mais otimizada.

ext3 e abaixo suportam até 32768 arquivos por diretório. O ext4 suporta até 65536 na contagem real de arquivos, mas permitirá que você tenha mais (ele simplesmente não os armazenará no diretório, o que não importa para a maioria dos usuários).

Além disso, a maneira como os diretórios são armazenados nos sistemas de arquivos ext * é essencialmente uma grande lista. Nos sistemas de arquivos mais modernos (Reiser, XFS, JFS), eles são armazenados como árvores B, muito mais eficientes para conjuntos grandes.

Você pode armazenar inodes de arquivos em vez de nomes de arquivos: acessar números de inode deve ser muito mais rápido que resolver nomes de arquivos

Você não quer empinar tantos arquivos em um diretório, quer algum tipo de estrutura. Mesmo que seja algo tão simples quanto ter subdiretórios que começam com o primeiro caractere do arquivo, pode melhorar o tempo de acesso. Outro truque bobo que eu gosto de usar é forçar o sistema a atualizar seu cache com metainformações e executar o updateb regularmente. Em uma janela, execute slabtop e, em outra, atualizeb, e você verá que muita memória será alocada para o cache. É muito mais rápido assim.

Você não especificou o tipo de dados nesses arquivos. Mas, pelo que parece, você deve usar algum tipo de banco de dados com indexação para pesquisas rápidas.

O sistema de arquivos provavelmente não é o armazenamento ideal para esse requisito. Algum tipo de armazenamento de banco de dados é melhor. Ainda assim, se você não puder ajudá-lo, tente dividir os arquivos em vários diretórios e use o unionfs para montar (ligar) esses diretórios no diretório único onde você deseja que todos os arquivos apareçam. Eu não usei essa técnica para acelerar, mas vale a pena tentar.