Qual é o sistema de arquivos Linux de mais alto desempenho para armazenar muitos arquivos pequenos (HDD, não SSD)?

43

Eu tenho uma árvore de diretórios que contém muitos arquivos pequenos e um pequeno número de arquivos maiores. O tamanho médio de um arquivo é de aproximadamente 1 kilobyte. Há 210158 arquivos e diretórios na árvore (este número foi obtido através da execução find | wc -l).

Uma pequena porcentagem de arquivos é adicionada / excluída / reescrita várias vezes por semana. Isso se aplica aos arquivos pequenos, bem como ao (pequeno número de) arquivos maiores.

Os sistemas de arquivos que eu tentei (ext4, btrfs) têm alguns problemas com o posicionamento dos arquivos no disco. Por um período maior, as posições físicas dos arquivos no disco (mídia rotativa, não disco de estado sólido) estão se tornando mais distribuídas aleatoriamente. A conseqüência negativa dessa distribuição aleatória é que o sistema de arquivos está ficando mais lento (como: 4 vezes mais lento que um sistema de arquivos novo).

Existe um sistema de arquivos Linux (ou um método de manutenção do sistema de arquivos) que não sofre com essa degradação do desempenho e é capaz de manter um perfil de desempenho estável em uma mídia rotativa? O sistema de arquivos pode ser executado no Fuse, mas precisa ser confiável.

linux filesystems performance
fonte
Se você souber quais arquivos serão grandes / não serão alterados com muita frequência e quais serão pequenos / serão alterados com frequência, convém criar dois sistemas de arquivos com opções diferentes, mais adequados a cada cenário. Se você precisar que eles estejam acessíveis, como parte da mesma estrutura, você pode fazer alguns truques com mount, symlinks.
Marcin
Fico muito surpreso ao saber que o btrfs (com o recurso de copiar na gravação) ficou lento para você por um período de tempo. Estou curioso para ter os resultados compartilhados com você, possivelmente ajudando um ao outro em uma nova direção de ajuste de desempenho.
Nikhil Mulley
existe um novo zfs online para animais no Linux, disponível no modo nativo e implementações de fusíveis, caso você queira dar uma olhada.
Nikhil Mulley
Eu tentei o zfs no linux uma vez, era bastante instável. Conseguiu bloquear completamente o sistema de arquivos com bastante frequência. Box funcionaria, mas qualquer acesso ao FS seria interrompido.
Patrick
Semelhante pós serverfault.com/questions/6711/...
Nikhil Mulley

Respostas:

47

atuação

Eu escrevi um pequeno Benchmark ( fonte ), para descobrir qual sistema de arquivos funciona melhor com centenas de milhares de arquivos pequenos:

  • crie 300000 arquivos (512B a 1536B) com dados de / dev / urandom
  • reescreva 30000 arquivos aleatórios e altere o tamanho
  • ler 30000 arquivos seqüenciais
  • leia 30000 arquivos aleatórios

  • excluir todos os arquivos

  • sincronizar e soltar cache após cada etapa

Resultados (tempo médio em segundos, menor = melhor):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Resultado:
Embora o Ext4 tenha um bom desempenho geral, o ReiserFS foi extremamente rápido na leitura de arquivos seqüenciais. Acontece que o XFS é lento com muitos arquivos pequenos - você não deve usá-lo neste caso de uso.

Problema de fragmentação

A única maneira de impedir que os sistemas de arquivos distribuam arquivos pela unidade é manter a partição do tamanho que você realmente precisa, mas preste atenção para não tornar a partição muito pequena, para evitar a fragmentação intra-arquivo. Usar o LVM pode ser muito útil.

Leitura adicional

O Arch Wiki possui ótimos artigos sobre o desempenho do sistema de arquivos:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

taffer
fonte
4
Você deve especificar em qual versão do kernel você está baseando a comparação. O XFS obteve algumas melhorias de velocidade muito significativas em um dos kernels recentes (acho que era 2.6.31, mas não me cite nisso).
Patrick Patrick
1
O btrfs internamente faz seu truque lvm. Ele aloca pedaços menores do disco e coloca arquivos nesses pedaços, depois aloca outro pedaço do disco apenas quando os pedaços existentes forem preenchidos.
Psusi
1
Isso é verdade para qualquer sistema de arquivos. É por isso que os aplicativos usam coisas como fsync ().
Psusi
2
@ taffer, é. As transações têm o mesmo efeito que o diário em outros sistemas de arquivos: protegem os metadados fs. Em teoria, eles podem ser usados ​​pelos aplicativos da maneira que você descreve, mas atualmente não existe uma API que permita aos aplicativos abrir e fechar transações.
Psusi
1
@taffer Sua "referência recente" é de abril de 2015, com mais de três anos e usa o XFS apenas com opções padrão. Isso antecede o xfsprogs 3.2.3, que torna o XFS v5 o padrão e todos os benefícios que ele traz. Também não foi formatado com -m finobt = 1, que muda o desempenho do XFS com arquivos pequenos e atualizações pesadas de metadados. Não, não existem marcadores de prata, mas basear sua opinião em benchmarks antigos com isso não é prudente, especialmente quando os principais recursos de alteração de desempenho foram ignorados, indisponíveis ou desativados.
Jody Lee Bruchon
7

Estou usando o ReiserFS para esta tarefa, especialmente feita para lidar com muitos arquivos pequenos. Existe um texto fácil de ler sobre isso no wiki do funtoo.

O ReiserFS também possui uma série de recursos destinados especificamente a melhorar o desempenho de arquivos pequenos. Diferentemente do ext2, o ReiserFS não aloca espaço de armazenamento em um ou quatro blocos fixos. Em vez disso, ele pode alocar o tamanho exato necessário.

Baarn
fonte
1
Também existem problemas de estabilidade no ReiserFS - portanto, o RH e o SuSE eliminaram esse FS. A partir do princípio (FS baseado no BTree), o BTRFS deve ser comparável.
Nils
0

O XFS é conhecido por ter um desempenho muito bom em situações como esta. Isso é parte do motivo de usá-lo no meu trabalho para nossos armazenamentos de correio (que pode conter centenas de milhares de arquivos em um diretório). Possui melhor tolerância a falhas que o ReiserFS, é muito mais usado e geralmente é um sistema de arquivos muito maduro.

Além disso, o XFS oferece suporte à desfragmentação online. Embora ele use uma técnica de alocação atrasada que resulta em menos fragmentação (vs outros sistemas de arquivos) para começar.

Patrick
fonte
20
O XFS é conhecido por ter um desempenho muito bom em situações como esta. [citação necessário]
taffer 14/01
8
Ehm, xfs é especialmente conhecido pelo contrário: trabalhando muito bem com arquivos grandes, mas não tão bem com arquivos pequenos! Veja este ponto de referência exaustivo, por exemplo (ou vá
Levite
1
@ Levit Eu acho que você está interpretando mal esse relatório. O relatório mostra claramente que o XFS funciona muito bem para E / S aleatórias. Mas, tirando isso, o relatório não aborda o tipo de cenário nesta pergunta, muitos arquivos. E / S aleatória é uma coisa: um grande número de arquivos é onde o ext * cai de cara no chão.
Patrick
2
O único lugar em que o XFS é realmente melhor são as operações aleatórias de leitura / gravação (ainda parece estranho que um padrão de leitura verdadeiramente aleatório em um disco mecânico seja capaz de obter 10 MB / s - me parece uma otimização que não voa no mundo real (imho)), enquanto na página 7 mostra exatamente o que eu disse anteriormente, o XFS é realmente bom no manuseio de arquivos grandes! Veja as páginas 3 e 5, especialmente a versão 3, que você vê lidar com arquivos pequenos claramente não tão bem quanto ext! Eu realmente não tenho nada contra o XFS, mas pelo que você encontra em qualquer lugar, não é a melhor opção para muitos arquivos pequenos, é tudo o que estou dizendo!
Levite
5
O XFS também pode ser extremamente lento quando se trata de arquivos grandes, se esses arquivos forem estendidos aleatoriamente / lentamente com pequenos pedaços por um longo tempo. (O syslogdpadrão típico .) Por exemplo, ao meu lado em uma configuração de XFS sobre MD, observei que a remoção de um arquivo de 1,5 GB levou 4,75 minutos (!) Enquanto a unidade de disco estava limitada a um limite de 100 transações / s a ​​uma taxa de gravação de mais de 2 MB / s. Isso também afeta muito o desempenho de outras operações de E / S em paralelo na mesma unidade, pois a unidade já está no máximo. Nunca vi nada parecido em outros FS (ou sendo testado em benchmarks).
Tino