Estou montando uma caixa de Linux que funcionará como um servidor de compilação de integração contínua; nós vamos principalmente construir coisas Java, mas eu acho que essa questão se aplica a qualquer linguagem compilada.
Quais configurações de sistema de arquivos e configurações devo usar? (Por exemplo, sei que não precisarei de tempo para isso!) O servidor de compilação gastará muito tempo lendo e gravando arquivos pequenos e varrendo 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 simplesmente limpar e refazer a imagem; as compilações continuarão sendo executadas 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, union monta um ramdisk tmpfs em cima disso para que os arquivos escritos durante as compilações obtenham os benefícios do ramdisk. Altere o procedimento de construção para mover os binários resultantes dos tmpfs no final da compilação ou mescle os tmpfs de volta no ext4fs antes de desmontar.
Sistema de arquivos mais rápido? tmpfs montados fora da RAM disponível, com noatime set.
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ê reinicializar) e se a origem e os objetos se encaixarem em um canto razoável de sua RAM disponível (com o suficiente para executar o seu compilador e vinculador sem trocar). Dito isso, você não pode deixar de funcionar com a RAM para ter 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 os ambientes de criação criam muitos arquivos.
Para fontes, é preferível ter suporte a compressão em tempo real, que é Reiser4 ou Btrfs . Ambos são "não para produção" ainda, embora eu tenha ouvido falar de pessoas usando ambas as FS pesadamente e felizmente. : -)
A próxima escolha (eu costumo fazer) é Reiser3 , não Ext3 . O ext3 pode ser um pouco mais rápido hoje em dia, mas o Reiser3 não possui limites de tempo de formato i-nodes, suporta a mudança on-line da opção "data=". Ele tem suporte a "cauda" que permite arquivos minúsculos mais apertados, mas se você estiver preocupado com a velocidade, "notale" isso.
Tanto o XFS quanto o JFS seriam um problema para o caso de "muitos arquivos pequenos", especialmente se você precisar deles.
(Esqueci de mencionar EXT4: Sim, é ainda mais rápido, então EXT3. Mas todas as limitações do EXT3 mencionadas acima 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:
Btrfs e Ext4 são três dos itens acima e o quarto é questionável. O Ext4 provavelmente é maduro o suficiente para isso, mas o btrfs não é feito ainda. O noatime ajuda a tornar as operações de meta-dados mais eficientes, mas quando você está criando um monte de novos arquivos, você ainda precisa que as operações de meta-data sejam extremamente rápidas.
É quando o armazenamento subjacente começa a se tornar um fator. As operações de meta-dados XFS tendem a se concentrar em poucos 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) não importa significativamente .
Cada sistema de arquivos tem poucos aprimoramentos que podem ser feitos para exibir mais alguns pontos percentuais. O desempenho do armazenamento subjacente afetará muito o volume de ganho que você verá.
No jargão do armazenamento, se você tiver sobrecarga de Operação de E / S suficiente em seu armazenamento, as ineficiências do sistema de arquivos começam a não importar muito. Se você usa um SSD para sua partição de construção, a escolha do sistema de arquivos é menos importante do que o que você está mais confortável trabalhando.
Para muitos arquivos pequenos, eu recomendaria o Reiser sobre o ext3, xfs, jfs ..., embora eu tenha ouvido que o ext4 é muito melhor (ou seja, oposto ao que o poise diz) do que suas encarnações anteriores para esse padrão de acesso.
O Reiser faz com que muitos dos arquivos estruturem a árvore de inode - então funciona muito bem quando se lida com arquivos pequenos.
No entanto, as diferenças de comportamento entre os principais sistemas de arquivos são relativamente pequenas comparadas aos benefícios que você obterá tendo memória física suficiente para armazenar em cache / buffer efetivamente.
and scanning directories to see which files have been modified.
Esta é uma maneira ruim para resolver o problema - mesmo que seja relativamente simples. Se for assim tão importante, pense em escrever um manipulador inotify para indexar os mods.
OTOH, se você estiver usando SSD flash (o que lhe dará tempos de busca muito baixos), eu recomendaria usar um fs que distribui a gravação de forma mais eficaz por motivos de longevidade - por exemplo, JFFS2