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

29

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?

bugmenot77
fonte
3
Por que eles devem estar em um diretório?
Kyle Brandt
1
Também estou interessado em uma resposta atualizada à pergunta original, dadas as melhorias suficientes no xfs e ext4.

Respostas:

15

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.

Kamil Kisiel
fonte
de acordo com os slides da resposta de @ nelaar, ext4 seria superior ao xfs para esta tarefa.
mulllhausen
13

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

hora de executar o mkfs hora de criar arquivos de 1 milhão de 50 kb Tempo de reparo do sistema de arquivos removendo arquivos de 1m

nelaaro
fonte
2
Nós realmente preferimos que as respostas contenham conteúdo e não ponteiros para o conteúdo. Embora isso possa teoricamente responder à pergunta, seria preferível incluir aqui as partes essenciais da resposta e fornecer o link para referência.
user9517 suporta GoFundMonica
@Iain Espero que seja melhor, pois basta baixar o PDF e fornecer as mesmas informações.
Aiaro
19
wow estes são alguns excepcionalmente difícil de ler gráficos ~.
ThorSummoner
8

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.

Ludwig Weinzierl
fonte
5

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.

bugmenot77
fonte
5

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.

Matt
fonte
3

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.

Kyle Brandt
fonte
1
foi /dev/sad1intencional para evitar erros de cópia / massa?
Anwar
2

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.

koenigdmj
fonte
2
dar suporte a esse número de arquivos em um diretório não é a mesma coisa que fazê-lo a uma velocidade razoável. Ainda não sei se o ext4 é melhor, mas o ext3 diminui bastante quando há mais de alguns milhares de arquivos em um diretório, mesmo com o dir_index ativado (ajuda, mas não elimina completamente o problema).
18285
1

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

Kolypto
fonte
Agora me diga. Como você abre um arquivo por número de inode?
Matt
1
@ Matt, parece que a pergunta mudou depois que eu respondi. Ou eu era muito mais estúpido a 1,5 anos atrás :))) #
kolypto
0

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.

Marcin
fonte
-1

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.

xeon
fonte
-1

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.

Saurabh Barjatiya
fonte