Desempenho de operações de arquivo em milhares de arquivos em NTFS vs HFS, ext3, outros

Question

[Crossposted do meu Pergunte à postagem da HN . Sinta-se à vontade para fechá-lo se a pergunta for muito ampla para o superusuário.]

Isso é algo que eu tenho curioso há anos, mas nunca encontrei nenhuma boa discussão sobre o assunto. É claro que meu Google-fu pode estar acabando comigo ...

Costumo lidar com projetos que envolvem milhares de arquivos relativamente pequenos. Isso significa que estou freqüentemente executando operações em todos esses arquivos ou em um grande subconjunto deles - copiando a pasta do projeto em outro lugar, excluindo um monte de arquivos temporários, etc. De todas as máquinas em que trabalhei ao longo dos anos, eu Notei que o NTFS lida com essas tarefas consistentemente mais lento que o HFS em um Mac ou ext3 / ext4 em uma caixa do Linux. No entanto, tanto quanto eu posso dizer, a taxa de transferência bruta não é realmente mais lenta em NTFS (pelo menos não significativamente), mas o atraso entre cada arquivo individual é apenas um pouquinho mais longo. Esse pequeno atraso realmente resulta em milhares de arquivos.

(Nota: De acordo com o que eu li, essa é uma das razões pelas quais o git é tão problemático no Windows, já que depende muito do sistema de arquivos para seu banco de dados de objetos.)

Com certeza, minha evidência é meramente anedótica - atualmente não tenho nenhum número real de desempenho, mas é algo que eu adoraria testar ainda mais (talvez com uma inicialização dupla do Mac no Windows). Ainda assim, minha geekiness insiste que alguém lá fora já tenha.

Alguém pode explicar isso, ou talvez me apontar na direção certa para pesquisar mais eu mesmo?

    

Answer 1

Não sou especialista em HFS, mas examinei sistemas de arquivos NTFS e ext3. Parece que você deveria considerar duas coisas.

Primeiro, os sistemas de arquivos ext2 / 3/4 pré-alocam as áreas no disco para armazenar metadados de arquivos (permissões, propriedade, os blocos ou extensões que compõem os dados do arquivo). Eu não acho que o NTFS faça. O equivalente a um ext3 "inode" é o registro $ MFT. É meu entendimento que os registros $ MFT não são necessariamente alocados quando você cria um arquivo. $ MFT pode ser cultivado, se necessário. É muito mais difícil aumentar o número de inodes em um sistema de arquivos ext2 / 3/4.

Eu não estou a par de qualquer parte interna do NT, mas tudo lê como os registros $ MFT são criados conforme necessário, então você pode ter arquivos pequenos, diretórios, arquivos grandes intercalados.

Para sistemas de arquivos no estilo BSD FFS, o que os sistemas de arquivos ext2 / 3/4 definitivamente possuem, muitos foram dedicados ao agrupamento de inodes em disco e a separação dos arquivos de diretório dos inodes. Muito foi dedicado a escrever diretórios e metadados de forma eficiente e segura. Veja: link como um exemplo.

Segundo, os dados para arquivos pequenos são mantidos nos registros $ MFT, se eu ler as coisas corretamente. Isso não é verdade para o ext2 / 3/4, e é por isso que mencionei acima que arquivos pequenos e arquivos grandes são tratados de maneira um pouco diferente.

Parece-me que o NT (o sistema operacional) está sofrendo de contenção por $ MFT. Os diretórios são atualizados, o que é uma atualização de registro de $ MFT. Arquivos pequenos são criados, o que é uma atualização do $ MFT. O sistema operacional não pode ordenar leituras e gravações de forma eficiente, porque todas as atualizações de metadados e as gravações de dados vão para o mesmo "arquivo", $ MFT.

Mas, como eu disse, apenas um palpite. Meu conhecimento de NTFS é principalmente de leitura e apenas um pouco de experimentar com ele. Você poderia checar meu palpite vendo se o HFT mantém os "diretórios" separados dos "inodes" separados dos "dados do arquivo". Se isso acontecer, isso pode ser uma grande dica.