Desempenho ruim do NTFS

Question

Por que o desempenho do NTFS é tão ruim comparado a, por exemplo, Linux / ext3? Na maioria das vezes eu vejo isso quando checo as árvores fonte (grandes) do Subversion. O check-out leva de 10 a 15 minutos em NTFS, enquanto o check-out correspondente no Linux (em hardware quase idêntico) leva uma ordem de magnitude mais rápida (1 a 1,5 minutos).

Talvez isso seja específico para lidar com muitos arquivos pequenos e o NTFS é melhor quando se trata de arquivos grandes, mas por que deveria ser isso? O aprimoramento do desempenho do NTFS para arquivos pequenos não seria extremamente benéfico para o desempenho do Windows em geral?

EDIT: Isto não é como uma pergunta inflamatória "NTFS é uma droga em comparação com ext3"; Estou genuinamente interessado em por que o NTFS tem desempenho ruim em certos casos. É apenas design ruim (o que duvido), ou existem outras questões que entram em jogo?

    

Answer 1

O NTFS tem essa coisa chamada Tabela de arquivos mestre . Parece muito legal quando você lê sobre isso.

Você pode ver que o ext3 executa bem até cerca de 95% de uso do disco, enquanto a existência da MFT significa que o NTFS realmente não quer que você use mais de 90% do seu disco. Mas vou assumir que não é problema seu, e que o seu problema é com as muitas operações em muitos arquivos pequenos.

Uma das diferenças aqui é o que acontece quando você cria um arquivo pequeno. Se um arquivo é menor que um tamanho de bloco, ele não é gravado em seu próprio bloco, mas é armazenado na MFT. Isso é bom se o arquivo permanecer exatamente como foi quando criado. Na prática, porém, isso significa que quando o svn toca em um arquivo para criá-lo, então adiciona ao arquivo, remove dele ou apenas o modifica por não o suficiente para movê-lo para seu próprio bloco, a operação é bem lenta. Também apenas ler muitos arquivos pequenos coloca um pouco de ênfase na MFT, onde todos residem, com múltiplos por bloco. Por que faria isso? Prevenentemente evita a fragmentação e usa mais blocos de maneira mais eficaz e, em geral, isso é bom.

No ext2 e no 3, os blocos de arquivos de cada arquivo são armazenados ao lado de onde estão os metadados do diretório (quando possível, se o disco não tiver desfragmentado e você tiver 20% de espaço livre). Isto significa que como o svn está abrindo diretórios, um número de blocos é armazenado em cache basicamente no cache de 16MB da sua unidade, e novamente no cache do kernel. Esses arquivos podem incluir o arquivo .svn e os arquivos de revisão da sua última atualização. Isso é útil, já que esses são provavelmente alguns dos arquivos que o svn está procurando. O NTFS não consegue fazer isso, embora partes grandes da MFT devam ser armazenadas em cache no sistema, elas podem não ser as partes que você desejará a seguir.

    

Answer 2

Bem, seu problema específico é porque

1. O próprio Subversion vem do mundo do UNIX, portanto, a versão do Windows pressupõe características de desempenho semelhantes.
2. O desempenho do NTFS realmente não é ótimo com gazilhões de arquivos pequenos.

O que você está vendo é simplesmente um artefato de algo projetado para um sistema operacional específico com suposições de desempenho nesses sistemas operacionais. Isso geralmente falha muito quando levado para outros sistemas. Outros exemplos seriam forking vs. threading. Nos modos UNIX, a forma tradicional de paralisar algo é apenas gerar outro processo. No Windows, onde os processos levam pelo menos cinco vezes mais tempo para começar, essa é uma péssima ideia.

Em geral, você não pode simplesmente aceitar artefatos de um determinado sistema operacional em qualquer outro com arquitetura muito diferente. Também não se esqueça que o NTFS tem muitos recursos do sistema de arquivos que estavam ausentes nos sistemas de arquivos UNIX amplamente utilizados naquele momento, como o registro em diário e as ACLs. Essas coisas têm um custo.

Algum dia, quando tenho muito tempo livre, planejava escrever um módulo de sistema de arquivos SVN que aproveita os recursos que você tem em NTFS, como suporte a transações (deve eliminar o "problema de tocar milhões de arquivos pequenos") e fluxos de dados alternativos (devem eliminar a necessidade do diretório .svn separado). Seria bom ter, mas duvido que os desenvolvedores do SVN possam implementar tais coisas no futuro previsível.

Nota: Uma única atualização em um grande repositório SVN que estou usando levou cerca de 250.000 operações de arquivo. Uma pequena voz me diz que isso é realmente muito para 24 arquivos que mudaram ...

    

Answer 3

Veja as informações da Microsoft sobre como o NTFS funciona. Pode ser um exagero para o que você está procurando, mas estudá-lo pode lançar alguma luz sobre os cenários com os quais o NTFS tem problemas.