Desempenho NTFS e grandes volumes de arquivos e diretórios

Como o Windows com NTFS funciona com grandes volumes de arquivos e diretórios?

Existe alguma orientação sobre os limites de arquivos ou diretórios que você pode colocar em um único diretório antes de encontrar problemas de desempenho ou outros problemas?

Por exemplo, é bom ter uma pasta com 100.000 pastas dentro dela?

Aqui estão alguns conselhos de alguém com um ambiente em que temos pastas contendo dezenas de milhões de arquivos.

1. Uma pasta armazena as informações do índice (links para arquivos filho e pasta filho) em um arquivo de índice. Este arquivo ficará muito grande quando você tiver muitos filhos. Observe que ele não faz distinção entre um filho que é uma pasta e um filho que é um arquivo. A única diferença realmente é que o conteúdo desse filho é o índice de pastas do filho ou os dados do arquivo do filho. Nota: Estou simplificando isso um pouco, mas isso explica o ponto.
2. O arquivo de índice será fragmentado. Quando estiver muito fragmentado, você não poderá adicionar arquivos a essa pasta. Isso ocorre porque há um limite no número de fragmentos permitido. É por design. Confirmei com a Microsoft em uma chamada de incidente de suporte. Portanto, embora o limite teórico para o número de arquivos que você possa ter em uma pasta seja de vários bilhões, boa sorte quando você começar a atingir dezenas de milhões de arquivos, pois atingirá primeiro a limitação de fragmentação.
3. Não é tão ruim assim. Você pode usar a ferramenta: contig.exe para desfragmentar esse índice. Não reduzirá o tamanho do índice (que pode atingir vários Gigs por dezenas de milhões de arquivos), mas você pode reduzir o número de fragmentos. Nota: A ferramenta Desfragmentar disco NÃO desfragmentará o índice da pasta. Irá desfragmentar os dados do arquivo. Somente a ferramenta contig.exe desfragmentará o índice. FYI: Você também pode usá-lo para desfragmentar os dados de um arquivo individual.
4. Se você desfragmentar, não espere até atingir o número máximo de limites de fragmentos. Eu tenho uma pasta onde não posso desfragmentar porque esperei até que seja tarde demais. Meu próximo teste é tentar mover alguns arquivos dessa pasta para outra pasta para ver se eu poderia desfragmentá-lo. Se isso falhar, o que eu teria que fazer é 1) criar uma nova pasta. 2) mova um lote de arquivos para a nova pasta. 3) desfragmentar a nova pasta. repita # 2 e # 3 até que isso seja feito e, em seguida, 4) remova a pasta antiga e renomeie a nova pasta para corresponder à antiga.

Para responder sua pergunta mais diretamente: Se você estiver vendo 100 mil entradas, não se preocupe. Vá nocautear. Se você estiver vendo dezenas de milhões de entradas, então:

a) Faça planos para subdividi-los em subpastas (por exemplo, digamos que você tenha arquivos 100M. É melhor armazená-los em 1000 pastas para que você tenha apenas 100.000 arquivos por pasta do que armazená-los em uma pasta grande. criará 1000 índices de pastas em vez de um único grande, com maior probabilidade de atingir o número máximo de fragmentos ou

b) Faça planos para executar contig.exe regularmente para manter o índice da sua grande pasta desfragmentado.

Leia abaixo apenas se você estiver entediado.

O limite real não está no número de fragmento, mas no número de registros do segmento de dados que armazena os ponteiros no fragmento.

Então, o que você tem é um segmento de dados que armazena ponteiros para os fragmentos dos dados do diretório. Os dados do diretório armazenam informações sobre os subdiretórios e subarquivos que o diretório supostamente armazenou. Na verdade, um diretório não "armazena" nada. É apenas um recurso de rastreamento e apresentação que apresenta a ilusão de hierarquia ao usuário, pois o próprio meio de armazenamento é linear.

Também há problemas de desempenho com a criação de nomes curtos de arquivos, tornando as coisas mais lentas. A Microsoft recomenda desativar a criação de nome de arquivo curto se você tiver mais de 300k arquivos em uma pasta [1]. Quanto menos exclusivos os 6 primeiros caracteres, maior será o problema.

[1] Como o NTFS funciona em http://technet.microsoft.com , procure por "300.000"

Estou construindo uma estrutura de arquivos para hospedar até 2 bilhões (2 ^ 32) de arquivos e realizei os seguintes testes que mostram uma queda acentuada no desempenho de navegação + leitura em cerca de 250 arquivos ou 120 diretórios por diretório NTFS em uma unidade de estado sólido ( SSD):

• O desempenho do arquivo cai em 50% entre 250 e 1000 arquivos.
• O desempenho do diretório cai em 60% entre 120 e 1000 diretórios.
• Valores para números> 1000 permanecem relativamente estáveis

Curiosamente, o número de diretórios e arquivos NÃO interfere significativamente.

Portanto, as lições são:

• Os números de arquivo acima de 250 custam um fator de 2
• Diretórios acima de 120 custam um fator de 2,5
• O File Explorer no Windows 7 pode lidar com #Files ou #Dirs grandes, mas a Usabilidade ainda é ruim.
• A introdução de subdiretórios não é cara

Estes são os dados (2 medidas para cada arquivo e diretório):

(FOPS = File Operations per Second)
(DOPS = Directory Operations per Second)

#Files  lg(#)   FOPS    FOPS2   DOPS    DOPS2
   10   1.00    16692   16692   16421   16312
  100   2.00    16425   15943   15738   16031
  120   2.08    15716   16024   15878   16122
  130   2.11    15883   16124   14328   14347
  160   2.20    15978   16184   11325   11128
  200   2.30    16364   16052   9866    9678
  210   2.32    16143   15977   9348    9547
  220   2.34    16290   15909   9094    9038
  230   2.36    16048   15930   9010    9094
  240   2.38    15096   15725   8654    9143
  250   2.40    15453   15548   8872    8472
  260   2.41    14454   15053   8577    8720
  300   2.48    12565   13245   8368    8361
  400   2.60    11159   11462   7671    7574
  500   2.70    10536   10560   7149    7331
 1000   3.00    9092    9509    6569    6693
 2000   3.30    8797    8810    6375    6292
10000   4.00    8084    8228    6210    6194
20000   4.30    8049    8343    5536    6100
50000   4.70    7468    7607    5364    5365

E este é o código de teste:

[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
    var files = new List<string>();
    var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
    Directory.CreateDirectory(dir);
    Console.WriteLine("prepare...");
    const string FILE_NAME = "\\file.txt";
    for (int i = 0; i < numFilesInDir; i++) {
        string filename = dir + Guid.NewGuid();
        if (testDirs) {
            var dirName = filename + "D";
            Directory.CreateDirectory(dirName);
            using (File.Create(dirName + FILE_NAME)) { }
        } else {
            using (File.Create(filename)) { }
        }
        files.Add(filename);
    }
    //Adding 1000 Directories didn't change File Performance
    /*for (int i = 0; i < 1000; i++) {
        string filename = dir + Guid.NewGuid();
        Directory.CreateDirectory(filename + "D");
    }*/
    Console.WriteLine("measure...");
    var r = new Random();
    var sw = new Stopwatch();
    sw.Start();
    int len = 0;
    int count = 0;
    while (sw.ElapsedMilliseconds < 5000) {
        string filename = files[r.Next(files.Count)];
        string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
        len += text.Length;
        count++;
    }
    Console.WriteLine("{0} File Ops/sec ", count / 5);
    return numFilesInDir; 
}

100.000 devem ficar bem.

Eu (anedoticamente) vi pessoas tendo problemas com muitos milhões de arquivos e eu também tive problemas com o Explorer por não saber como contar mais de 60 e tantos mil arquivos, mas o NTFS deve ser bom para os volumes que você está falando.

Caso você esteja se perguntando, o número máximo técnico (e espero teórico ) de arquivos é: 4.294.967.295

Para acesso local, um grande número de diretórios / arquivos não parece ser um problema. No entanto, se você está acessando através de uma rede, há um desempenho notável após algumas centenas (especialmente quando acessado a partir de máquinas Vista (o XP para Windows Server com NTFS parecia correr muito mais rápido nesse sentido)).

Ao criar uma pasta com N entradas, você cria uma lista de N itens no nível do sistema de arquivos. Esta lista é uma estrutura de dados compartilhada em todo o sistema. Se você começar a modificar essa lista continuamente adicionando / removendo entradas, espero pelo menos alguma contenção de bloqueio nos dados compartilhados. Essa afirmação - teoricamente - pode afetar negativamente o desempenho.

Para cenários somente leitura, não consigo imaginar nenhum motivo para degradação do desempenho de diretórios com grande número de entradas.

Eu tinha experiência real com cerca de 100.000 arquivos (cada um com vários MBs) em NTFS em um diretório enquanto copiava uma biblioteca online.

Demora cerca de 15 minutos para abrir o diretório com o Explorer ou 7-zip.

Escrever uma cópia do site winhttracksempre ficará bloqueado após algum tempo. Também tratou do diretório, contendo cerca de 1 000 000 arquivos. Eu acho que o pior é que a MFT só pode ser percorrida sequencialmente.

Abrir o mesmo em ext2fsd no ext3 deu quase o mesmo tempo. Provavelmente, mudar para reiserfs (não reiser4fs) pode ajudar.

Tentar evitar essa situação é provavelmente o melhor.

Para seus próprios programas usando blobs sem fs, pode ser benéfico. É assim que o Facebook faz para armazenar fotos.