Prestazioni NTFS e grandi volumi di file e directory

Come funziona Windows con NTFS con grandi volumi di file e directory?

Esistono indicazioni sui limiti di file o directory che è possibile inserire in una singola directory prima di incorrere in problemi di prestazioni o altri problemi?

Ad esempio avere una cartella con 100.000 cartelle al suo interno è una cosa OK da fare?

Ecco alcuni consigli di qualcuno con un ambiente in cui abbiamo cartelle contenenti decine di milioni di file.

1. Una cartella memorizza le informazioni sull'indice (collegamenti a file figlio e cartella figlio) in un file indice. Questo file diventerà molto grande quando hai molti figli. Nota che non distingue tra un figlio che è una cartella e un figlio che è un file. L'unica differenza è che il contenuto di quel figlio è l'indice della cartella del figlio o i dati del file del figlio. Nota: sto semplificando un po 'questo, ma questo fa capire il punto.
2. Il file indice verrà frammentato. Quando diventa troppo frammentato, non sarai in grado di aggiungere file a quella cartella. Questo perché esiste un limite al numero di frammenti consentito. È di progettazione. L'ho confermato con Microsoft in una chiamata di incidente di supporto. Quindi, sebbene il limite teorico al numero di file che puoi avere in una cartella sia di diversi miliardi, buona fortuna quando inizi a colpire decine di milioni di file poiché colpirai prima la limitazione di frammentazione.
3. Non è tutto male comunque. È possibile utilizzare lo strumento: contig.exe per deframmentare questo indice. Non ridurrà la dimensione dell'indice (che può raggiungere fino a diversi concerti per decine di milioni di file) ma è possibile ridurre il numero di frammenti. Nota: lo strumento di deframmentazione dischi NON deframmenterà l'indice della cartella. Deframmenterà i dati del file. Solo lo strumento contig.exe deframmenterà l'indice. A proposito: puoi anche usarlo per deframmentare i dati di un singolo file.
4. Se esegui la deframmentazione, non aspettare fino a quando non raggiungi il numero massimo di limiti di frammento. Ho una cartella in cui non posso deframmentare perché ho aspettato che fosse troppo tardi. Il mio prossimo test è di provare a spostare alcuni file da quella cartella in un'altra cartella per vedere se potrei deframmentarla in seguito. In caso contrario, ciò che dovrei fare è 1) creare una nuova cartella. 2) spostare un batch di file nella nuova cartella. 3) deframmenta la nuova cartella. ripetere # 2 e # 3 fino a quando ciò non viene fatto, quindi 4) rimuovere la vecchia cartella e rinominare la nuova cartella in modo che corrisponda alla vecchia.

Per rispondere alla tua domanda in modo più diretto: se stai esaminando 100.000 voci, non preoccuparti. Vai a buttarti fuori. Se stai guardando decine di milioni di voci, allora:

a) Pianifica di suddividerli in sottocartelle (ad esempio, supponiamo che tu abbia 100 milioni di file. È meglio archiviarli in 1000 cartelle in modo da avere solo 100.000 file per cartella piuttosto che archiviarli in 1 grande cartella. creerà 1000 indici di cartelle invece di un singolo grande che ha maggiori probabilità di raggiungere il limite massimo di frammenti o

b) Pianificare l'esecuzione regolare contig.exe per mantenere la deframmentazione dell'indice della cartella principale.

Leggi di seguito solo se sei annoiato.

Il limite effettivo non è il numero di frammento, ma il numero di record del segmento di dati che memorizza i puntatori al frammento.

Quindi quello che hai è un segmento di dati che memorizza i puntatori ai frammenti dei dati della directory. I dati della directory memorizzano informazioni sulle sottodirectory e sui file secondari che la directory presumibilmente ha archiviato. In realtà, una directory non "memorizza" nulla. È solo una funzionalità di tracciamento e presentazione che presenta l'illusione della gerarchia all'utente poiché il supporto di archiviazione stesso è lineare.

Ci sono anche problemi di prestazioni con la creazione di nomi di file brevi che rallentano le cose. Microsoft consiglia di disattivare la creazione di nomi di file brevi se in una cartella sono presenti più di 300.000 file [1]. Meno unici sono i primi 6 caratteri, più questo è un problema.

[1] Come funziona NTFS da http://technet.microsoft.com , cerca "300.000"

Sto costruendo una struttura di file per ospitare fino a 2 miliardi (2 ^ 32) di file ed ho eseguito i seguenti test che mostrano un forte calo di Navigate + Leggi le prestazioni a circa 250 file o 120 directory per directory NTFS su un'unità a stato solido ( SSD):

• Le prestazioni dei file diminuiscono del 50% tra 250 e 1000 file.
• Le prestazioni della directory diminuiscono del 60% tra 120 e 1000 directory.
• I valori per Numeri> 1000 rimangono relativamente stabili

È interessante notare che il numero di directory e file NON interferisce in modo significativo.

Quindi le lezioni sono:

• I numeri di file superiori a 250 costano un fattore 2
• Le directory superiori a 120 costano un fattore 2,5
• File Explorer in Windows 7 è in grado di gestire file # grandi o #Dir, ma l'usabilità è ancora negativa.
• L'introduzione di sottodirectory non è costosa

Questi sono i dati (2 misure per ciascun file e directory):

(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 questo è il codice di prova:

[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 dovrebbero andare bene.

Ho visto (aneddoticamente) persone che avevano problemi con molti milioni di file e ho avuto problemi io stesso con Explorer solo non avendo la minima idea di come contare oltre 60-qualcosa di migliaia di file, ma NTFS dovrebbe essere buono per i volumi di cui stai parlando.

Nel caso ti stia chiedendo, il numero massimo di file tecnici (e spero teorici ) è: 4.294.967.295

Per l'accesso locale, un gran numero di directory / file non sembra essere un problema. Tuttavia, se si accede ad esso attraverso una rete, si nota un notevole aumento delle prestazioni dopo alcune centinaia (soprattutto quando si accede da macchine Vista (XP a Windows Server w / NTFS sembrava funzionare molto più veloce in questo senso)).

Quando si crea una cartella con N voci, si crea un elenco di N elementi a livello di file system. Questo elenco è una struttura di dati condivisi a livello di sistema. Se poi inizi a modificare questo elenco continuamente aggiungendo / rimuovendo voci, mi aspetto almeno un po 'di contesa sui dati condivisi. Questa tesi - teoricamente - può influire negativamente sulle prestazioni.

Per gli scenari di sola lettura non riesco a immaginare alcun motivo per il degrado delle prestazioni delle directory con un numero elevato di voci.

Ho avuto una vera esperienza con circa 100000 file (ciascuno con diversi MB) su NTFS in una directory durante la copia di una libreria online.

Sono necessari circa 15 minuti per aprire la directory con Explorer o 7-zip.

Scrivere copia del sito con winhttrackrimarrà sempre bloccato dopo qualche tempo. Si occupava anche della directory, contenente circa 1 000 000 di file. Penso che la cosa peggiore sia che la MFT può essere attraversata solo in sequenza.

Aprire lo stesso con ext2fsd su ext3 ha dato quasi lo stesso tempismo. Probabilmente può essere utile passare a reiserfs (non reiser4fs).

Cercare di evitare questa situazione è probabilmente il migliore.

Per i tuoi programmi usando BLOB senza alcun fs potrebbe essere utile. Questo è il modo in cui Facebook fa per archiviare le foto.