Qual é o sistema de arquivos mais rápido para compilações de desenvolvedores?

Estou montando uma caixa Linux que atuará como um servidor de compilação de integração contínua; vamos construir principalmente coisas sobre Java, mas acho que essa pergunta se aplica a qualquer linguagem compilada.

Que sistema de arquivos e definições de configuração devo usar? (Por exemplo, eu sei que não precisarei de um tempo para isso!) O servidor de compilação passará muito tempo lendo e escrevendo arquivos pequenos e verificando diretórios para ver quais arquivos foram modificados.

ATUALIZAÇÃO: a integridade dos dados é uma prioridade baixa neste caso; é apenas uma máquina de construção ... os artefatos finais serão compactados e arquivados em outro lugar. Se o sistema de arquivos na máquina de compilação for corrompido e perder todos os dados, podemos apenas limpar e re-imagem; As compilações continuarão em execução como antes.

Use ext4fs como o sistema de arquivos base com algumas opções de aceleração, como

noatime,data=writeback,nobh,barrier=0,commit=300

Em seguida, o union monte um ramdisk tmpfs além disso, para que os arquivos gravados durante as compilações obtenham os benefícios do ramdisk. Altere o procedimento de compilação para mover os binários resultantes dos tmpfs no final da compilação ou mescle os tmpfs novamente no ext4fs antes de desmontar.

Sistema de arquivos mais rápido? tmpfs montado fora da RAM disponível, com noatimeset.

Isso só é viável se você tiver um procedimento para verificar tudo o que é necessário para construir sua árvore de origem (já que o conteúdo de um sistema de arquivos tmpfs desaparecerá quando você reiniciar) e se a origem e os objetos couberem em um canto razoável da RAM disponível ( sobrando o suficiente para executar seu compilador e vinculador sem trocar). Dito isto, você não pode vencer o trabalho fora da RAM para velocidade ..

Para a resposta de Michael Dillon, posso acrescentar que você pode criar um sistema de arquivos ext4 com poucas opções:

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 fornece mais inodes por tamanho, útil porque a criação de ambientes cria muitos arquivos.

Para fontes, é preferível ter suporte à compactação em tempo real, que é Reiser4 ou Btrfs . Ambos "ainda não estão em produção", embora eu tenha ouvido falar de pessoas que usam os FSs de maneira intensa e feliz. :-)

A próxima opção (geralmente) é Reiser3 , não Ext3 . Atualmente, o Ext3 pode ser um pouco mais rápido, mas o Reiser3 não possui limites de tempo de formato dos nós-i, suporta a alteração on-line da opção "data =". Ele tem suporte para "cauda", permitindo a compactação de arquivos menores e mais pequenos, mas se você estiver preocupado com a velocidade, "registre".

Tanto o XFS quanto o JFS seriam um problema para o caso de "muitos arquivos pequenos", especialmente se você precisar movê-los.

(Esqueceu-se de mencionar EXT4: Sim, é ainda mais rápido que o EXT3. Mas todas as limitações do EXT3 acima mencionadas também são do EXT4).

As operações que você descreve fornecem algumas dicas importantes sobre o que o sistema de arquivos ideal precisa ser capaz de fazer:

• Acessos massivamente aleatórios r / w durante o processo de compilação.
• Muitos arquivos são atualizados em pouco tempo, portanto, operações rápidas de metadados são críticas.
• Manuseio eficiente de muitos arquivos pequenos em sistemas de arquivos possivelmente muito pesados.
• Maduras o suficiente para não arriscar a perda de dados em casos extremos e obscuros.

Btrfs e Ext4 são três dos itens acima e o quarto é questionável. O Ext4 provavelmente está maduro o suficiente para isso, mas o btrfs ainda não está pronto. noatimeajuda a tornar as operações de metadados mais eficientes, mas quando você está criando um monte de novos arquivos, ainda precisa de operações de metadados para ser extremamente rápido.

É quando o armazenamento subjacente começa a se tornar um fator. As operações de metadados XFS tendem a se concentrar em alguns blocos, o que pode sobrecarregar as operações. Os sistemas de arquivos no estilo Ext são melhores para aproximar os metadados dos dados que estão descrevendo. No entanto, se o seu armazenamento for suficientemente abstrato (você está executando em um VPS ou conectado a uma SAN) , isso não importa significativamente .

Cada sistema de arquivos tem poucas acelerações que podem ser feitas para obter mais alguns pontos percentuais. O desempenho do armazenamento subjacente afetará muito o ganho que você verá.

Na linguagem do armazenamento, se você tiver sobrecarga suficiente de Operação de E / S em seu armazenamento, as ineficiências do sistema de arquivos começam a não ter tanta importância. Se você usa um SSD para sua partição de compilação, a escolha do sistema de arquivos é menos importante do que você se sente mais confortável trabalhando.

Para muitos arquivos pequenos, eu recomendo o Reiser sobre ext3, xfs, jfs ..., embora eu tenha ouvido falar que o ext4 é muito melhor (ou seja, o oposto do que diz poise) do que suas encarnações anteriores para esse padrão de acesso.

O Reiser empurra muitos dos arquivos para a árvore de inodes - portanto, ele funciona muito bem ao lidar com arquivos pequenos.

No entanto, as diferenças de comportamento entre os principais sistemas de arquivos são relativamente pequenas em comparação com os benefícios que você obtém por ter memória física suficiente para armazenar em cache / armazenar em buffer de maneira eficaz.

e varrendo diretórios para ver quais arquivos foram modificados.

Essa é uma maneira ruim de resolver o problema - mesmo que seja relativamente simples. Se isso é importante, pense em escrever um manipulador inotify para indexar os mods.

OTOH, se você estiver usando flash SSD (o que proporcionará tempos de busca muito baixos), eu recomendaria o uso de um fs que distribui a gravação de maneira mais eficaz por motivos de longevidade - por exemplo, JFFS2