NTFS-Leistung und große Mengen an Dateien und Verzeichnissen

Wie funktioniert Windows mit NTFS mit großen Mengen an Dateien und Verzeichnissen?

Gibt es Hinweise zu den Grenzen von Dateien oder Verzeichnissen, die Sie in einem einzelnen Verzeichnis ablegen können, bevor Sie auf Leistungsprobleme oder andere Probleme stoßen?

Ist es beispielsweise in Ordnung, einen Ordner mit 100.000 Ordnern darin zu haben?

Hier einige Ratschläge von jemandem in einer Umgebung, in der wir Ordner mit zig Millionen Dateien haben.

1. Ein Ordner speichert die Indexinformationen (Links zu untergeordneten Dateien und untergeordneten Ordnern) in einer Indexdatei. Diese Datei wird sehr groß, wenn Sie viele Kinder haben. Beachten Sie, dass nicht zwischen einem untergeordneten Ordner und einer untergeordneten Datei unterschieden wird. Der einzige Unterschied besteht darin, dass der Inhalt dieses Kindes entweder der Ordnerindex des Kindes oder die Dateidaten des Kindes sind. Hinweis: Ich vereinfache dies etwas, aber dies bringt den Punkt auf den Punkt.
2. Die Indexdatei wird fragmentiert. Wenn es zu fragmentiert ist, können Sie diesem Ordner keine Dateien hinzufügen. Dies liegt daran, dass die Anzahl der zulässigen Fragmente begrenzt ist. Es ist beabsichtigt. Ich habe es mit Microsoft in einem Support-Vorfall bestätigt. Obwohl die theoretische Grenze für die Anzahl der Dateien, die Sie in einem Ordner haben können, mehrere Milliarden beträgt, wünschen wir Ihnen viel Glück, wenn Sie zig Millionen Dateien erreichen, da Sie zuerst die Fragmentierungsbeschränkung erreichen.
3. Es ist jedoch nicht alles schlecht. Mit dem Tool: contig.exe können Sie diesen Index defragmentieren. Dadurch wird die Größe des Index nicht verringert (der für mehrere zehn Millionen Dateien bis zu mehreren Gigs erreichen kann), aber Sie können die Anzahl der Fragmente verringern. Hinweis: Das Tool zum Defragmentieren von Datenträgern defragmentiert NICHT den Index des Ordners. Dateidaten werden defragmentiert. Nur das Tool contig.exe defragmentiert den Index. Zu Ihrer Information: Sie können dies auch verwenden, um die Daten einer einzelnen Datei zu defragmentieren.
4. Wenn Sie defragmentieren, warten Sie nicht, bis Sie das maximale Fragmentlimit erreicht haben. Ich habe einen Ordner, in dem ich nicht defragmentieren kann, weil ich gewartet habe, bis es zu spät ist. Mein nächster Test besteht darin, einige Dateien aus diesem Ordner in einen anderen Ordner zu verschieben, um festzustellen, ob ich sie dann defragmentieren kann. Wenn dies fehlschlägt, müsste ich 1) einen neuen Ordner erstellen. 2) Verschieben Sie einen Stapel von Dateien in den neuen Ordner. 3) Defragmentieren Sie den neuen Ordner. Wiederholen Sie die Schritte 2 und 3, bis dies erledigt ist. 4) Entfernen Sie den alten Ordner und benennen Sie den neuen Ordner so um, dass er mit dem alten übereinstimmt.

Um Ihre Frage direkter zu beantworten: Wenn Sie sich 100.000 Einträge ansehen, machen Sie sich keine Sorgen. Geh und schlag dich aus. Wenn Sie sich zig Millionen Einträge ansehen, dann entweder:

a) Planen Sie, sie in Unterordner zu unterteilen (z. B. 100 Millionen Dateien. Es ist besser, sie in 1000 Ordnern zu speichern, sodass Sie nur 100.000 Dateien pro Ordner haben, als sie in einem großen Ordner zu speichern erstellt 1000 Ordnerindizes anstelle eines einzelnen großen, der mit größerer Wahrscheinlichkeit die maximale Anzahl von Fragmenten oder erreicht

b) Planen Sie, contig.exe regelmäßig auszuführen, um den Index Ihres großen Ordners defragmentiert zu halten.

Lesen Sie weiter unten nur, wenn Sie sich langweilen.

Die tatsächliche Grenze liegt nicht bei der Anzahl der Fragmente, sondern bei der Anzahl der Datensätze des Datensegments, in dem die Zeiger auf das Fragment gespeichert sind.

Sie haben also ein Datensegment, in dem Zeiger auf die Fragmente der Verzeichnisdaten gespeichert sind. In den Verzeichnisdaten werden Informationen zu den Unterverzeichnissen und Unterdateien gespeichert, die das Verzeichnis angeblich gespeichert hat. Tatsächlich "speichert" ein Verzeichnis nichts. Es ist nur eine Tracking- und Präsentationsfunktion, die dem Benutzer die Illusion einer Hierarchie präsentiert, da das Speichermedium selbst linear ist.

Es gibt auch Leistungsprobleme bei der Erstellung kurzer Dateinamen, die die Arbeit verlangsamen. Microsoft empfiehlt, die Erstellung kurzer Dateinamen zu deaktivieren, wenn sich mehr als 300.000 Dateien in einem Ordner befinden [1]. Je weniger eindeutig die ersten 6 Zeichen sind, desto problematischer ist dies.

[1] Wie NTFS Werke von http://technet.microsoft.com , wenn nach „300000“

Ich erstelle eine Dateistruktur, um bis zu 2 Milliarden (2 ^ 32) Dateien zu hosten, und habe die folgenden Tests durchgeführt, die einen starken Rückgang der Navigate + Read-Leistung bei etwa 250 Dateien oder 120 Verzeichnissen pro NTFS-Verzeichnis auf einem Solid State Drive ( SSD):

• Die Dateileistung sinkt zwischen 250 und 1000 Dateien um 50%.
• Die Verzeichnisleistung sinkt zwischen 120 und 1000 Verzeichnissen um 60%.
• Werte für Zahlen> 1000 bleiben relativ stabil

Interessanterweise stört die Anzahl der Verzeichnisse und Dateien NICHT wesentlich.

Die Lektionen sind also:

• Dateinummern über 250 kosten einen Faktor von 2
• Verzeichnisse über 120 kosten einen Faktor von 2,5
• Der Datei-Explorer in Windows 7 kann große #Files oder #Dirs verarbeiten, aber die Benutzerfreundlichkeit ist immer noch schlecht.
• Das Einführen von Unterverzeichnissen ist nicht teuer

Dies sind die Daten (2 Messungen für jede Datei und jedes Verzeichnis):

(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

Und das ist der Testcode:

[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 sollten in Ordnung sein.

Ich habe (anekdotisch) Leute gesehen, die Probleme mit vielen Millionen Dateien hatten, und ich hatte selbst Probleme mit dem Explorer, nur ohne eine Ahnung zu haben, wie man über 60.000 Dateien zählt, aber NTFS sollte gut für die Volumes sein, von denen Sie sprechen.

Falls Sie sich fragen, beträgt die technische (und ich hoffe theoretische ) maximale Anzahl von Dateien: 4.294.967.295

Für den lokalen Zugriff scheint eine große Anzahl von Verzeichnissen / Dateien kein Problem zu sein. Wenn Sie jedoch über ein Netzwerk darauf zugreifen, tritt nach einigen hundert ein merklicher Leistungseinbruch auf (insbesondere beim Zugriff von Vista-Computern (XP auf Windows Server mit NTFS schien in dieser Hinsicht viel schneller zu laufen)).

Wenn Sie einen Ordner mit N Einträgen erstellen, erstellen Sie eine Liste mit N Elementen auf Dateisystemebene. Diese Liste ist eine systemweite gemeinsame Datenstruktur. Wenn Sie dann anfangen, diese Liste kontinuierlich zu ändern, indem Sie Einträge hinzufügen / entfernen, erwarte ich zumindest einige Sperrenkonflikte über gemeinsam genutzte Daten. Diese Behauptung kann - theoretisch - die Leistung negativ beeinflussen.

Für schreibgeschützte Szenarien kann ich mir keinen Grund für eine Leistungsverschlechterung von Verzeichnissen mit einer großen Anzahl von Einträgen vorstellen.

Ich hatte echte Erfahrung mit ungefähr 100 000 Dateien (jeweils mehrere MB) auf NTFS in einem Verzeichnis, während ich eine Online-Bibliothek kopierte.

Das Öffnen des Verzeichnisses mit Explorer oder 7-zip dauert ca. 15 Minuten.

Das Schreiben einer Site-Kopie mit winhttrackbleibt nach einiger Zeit immer hängen. Es befasste sich auch mit Verzeichnissen, die etwa 1 000 000 Dateien enthielten. Ich denke, das Schlimmste ist, dass die MFT nur nacheinander durchlaufen werden kann.

Das Öffnen unter ext2fsd auf ext3 ergab fast das gleiche Timing. Wahrscheinlich kann ein Wechsel zu reiserfs (nicht zu reiser4fs) helfen.

Der Versuch, diese Situation zu vermeiden, ist wahrscheinlich der beste.

Für Ihre eigenen Programme kann die Verwendung von Blobs ohne fs von Vorteil sein. So speichert Facebook Fotos.