Höchstwahrscheinlich nein, es wird kein Engpass sein. Mit NTFS-Junctions ist ein gewisser Aufwand 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 Junctions überhaupt nicht verwenden (was für mich das Kernproblem Ihrer Frage ist), aber ich bezweifle, dass Sie den Unterschied messen können.
Wo werden die Junctions gespeichert und zwischengespeichert?
Junctions ist Art von Analysepunkten, die alle in gespeichert sind $Extend\$Reparse
Metafile (ein weiterer berühmter Metafile ist $MFT
).
Wenn einer Datei oder einem Verzeichnis ein Analysepunkt zugeordnet ist, erstellt NTFS ein Attribut, das
$Reparse
nach dem Analysepunkt benannt wird. Dieses Attribut speichert den Reparaturcode und die Daten. Damit NTFS alle Analysepunkte auf einem Volume problemlos finden kann, speichert eine Metadatendatei mit dem Namen\$Extend\$Reparse
Einträge, die die Analysepunktdatei und die Verzeichnis-MFT-Eintragsnummern mit den zugehörigen Analysepunktcodes verbinden. NTFS sortiert die Einträge nach der MFT-Eintragsnummer im$R
Index.
Quelle: Inside Win2K NTFS, Teil 1 von Mark Russinovich
Diagramm wiedergeben
Quelle: Inside Win2K NTFS, Teil 1 von Mark Russinovich
Es gab Kommentare, dass Junctions in MFT gespeichert werden und MFT zwischengespeichert wird. Nun, wenn wir wissen, wo die Junctions gespeichert sind, würde ich glaubwürdige Quellen benötigen, um den Caching-Anspruch zu unterstützen. was ich nicht finden konnte.
Ich weiß es nicht, aber ich glaube nicht, dass es wichtig ist.
Gibt es ein dokumentiertes Szenario, in dem die Leistung von Cross Disk Junction beeinträchtigt wurde?
Ja, ARF ist auf dieses Problem gestoßen. Er setzte ein Benchmarking der Batch-Löschung kleiner Dateien, und als der Vorgang über die Junction hinweg durchgeführt wurde, war der limitierende Faktor nicht mehr die IO (wie erwartet), sondern die CPU. Dieser Benchmark wurde auch ausführlich auf GitHub diskutiert .