NTFS Junction Point von HDD zu SSD, führt dies zu Leistungsengpässen? (Steam Game Relocation)

Kann ein NTFS-Verbindungspunkt zwischen Festplatten einen Engpass verursachen? Oder wird die Junction im Speicher zwischengespeichert?

Insbesondere möchte ich Steam auf einer magnetischen Festplatte installieren. Dies bedeutet, dass alle Spiele dort installiert werden. Um von meiner SSD zu profitieren, werde ich die Spiele, die ich aktiv spiele, vom Steam-Verzeichnis auf der Festplatte auf die SSD verlagern.

Ich habe mich gefragt, ob dies zu Leistungsproblemen führen würde. Muss das Spiel jedes Mal, wenn es auf eine Datei zugreift, die Festplatte lesen, den Verbindungspunkt lesen, den neuen Pfad auf der SSD auflösen und dann die wahre Datei erhalten? Oder wird das Betriebssystem diese Neuausrichtung zwischenspeichern, sodass die Leistungsminderung nur beim ersten Mal auftritt?

Vielen Dank!

— ddtemplar
quelle

Die Definition eines Knotenpunktes ist direkt im zuständigen MFT-Eintrag hinterlegt. Da die MFT im Speicher zwischengespeichert ist, würde ich nicht erwarten, dass auf die Festplatte zugegriffen wird, wenn mit dem verknüpften Verzeichnis gearbeitet wird.

— Gene

Vielen Dank! Ich mache mir dann keine allzu großen Sorgen, es sei denn, ich merke merkwürdige Verlangsamungen.

— Ddtemplar

Selbst wenn auf die Festplatte zugegriffen werden müsste, um den Junction-Punkt zu lesen, ist sie winzig - der Lesevorgang wäre fast sofort beendet und muss nur einmal ausgeführt werden, da er zwischengespeichert würde.

— Adambean

Eine Randnotiz: Wenn Sie die Steam-Anwendung auf der SSD installieren, können Sie dennoch ändern, wo das Spiel in Steam installiert wird, ohne dass eine Junction erforderlich ist.

— Cybernard

Höchstwahrscheinlich nein, es wird kein Engpass sein. Mit NTFS-Junctions ist ein gewisser Overhead verbunden, der in Ihrem Szenario jedoch vernachlässigbar sein sollte.

Sie könnten den Overhead beseitigen, indem Sie die Daten physisch auf die SSD verschieben und überhaupt keine Junctions verwenden (was für mich das Hauptanliegen Ihrer Frage zu sein scheint), aber ich bezweifle, dass Sie den Unterschied messen können.

Wo werden die Junctions gespeichert und zwischengespeichert?

Junctions sind Arten von Analysepunkten, die alle in $Extend\$Reparse Metadateien gespeichert sind (eine weitere bekanntere Metadatei ist die $MFT).

Wenn einer Datei oder einem Verzeichnis ein Analysepunkt zugeordnet ist, erstellt NTFS ein Attribut mit dem Namen $Reparsedes Analysepunkts. Dieses Attribut speichert den Analysecode und die Daten. Damit NTFS problemlos alle Analysepunkte auf einem Volume finden kann, werden in einer Metadatendatei mit dem Namen \$Extend\$ReparseEinträge gespeichert , die die Analysepunktdatei und die Verzeichnis-MFT-Eintragsnummern mit den zugehörigen Analysepunktcodes verbinden. NTFS sortiert die Einträge nach der MFT-Eintragsnummer im $RIndex.

Quelle: Inside Win2K NTFS, Teil 1 von Mark Russinovich

Diagramm wiederholen

Quelle: Inside Win2K NTFS, Teil 1 von Mark Russinovich

Es gab Kommentare, dass Junctions in MFT gespeichert werden und dass MFT zwischengespeichert wird. Nun, wenn wir wissen, wo die Junctions gespeichert sind, würde ich eine glaubwürdige Quelle benötigen, um die Caching-Behauptung zu unterstützen. was ich nicht finden konnte.

Ich weiß es nicht, aber ich denke nicht, dass es wichtig ist.

Gibt es ein dokumentiertes Szenario, in dem eine plattenübergreifende Junction die Leistung verringert?

Ja, ARF hat sich zu laufen Problem wie dieses. Er führte ein Benchmarking für das Löschen kleiner Dateien im Batch durch, und als die Operation über Junction ausgeführt wurde, war der begrenzende Faktor nicht mehr (wie erwartet) IO, sondern die CPU. Dieser Benchmark wurde auch auf GitHub ausführlich besprochen .

— Vlastimil Ovčáčík
quelle