HDD から SSD への NTFS ジャンクション ポイントはパフォーマンスのボトルネックを引き起こしますか? (Steam ゲームの再配置)

HDD から SSD への NTFS ジャンクション ポイントはパフォーマンスのボトルネックを引き起こしますか? (Steam ゲームの再配置)

HDD 間の NTFS ジャンクション ポイントがボトルネックを引き起こす可能性がありますか? または、ジャンクションはメモリにキャッシュされますか?

具体的には、Steam を磁気 HDD にインストールします。つまり、すべてのゲームがそこにインストールされます。SSD のメリットを享受するために、現在プレイしているゲームを HDD 上の Steam のディレクトリから SSD にジャンクション ポイントします。

これがパフォーマンスの問題を引き起こすかどうか疑問に思っていました。ゲームがファイルにアクセスするたびに、HDD を読み取り、ジャンクション ポイントを読み取り、SSD 上の新しいパスを解決して、実際のファイルを取得する必要がありますか? それとも、OS がこのリダイレクトをキャッシュして、パフォーマンスの低下が最初の 1 回だけ発生するのでしょうか?

ありがとう!

答え1

おそらくそうではありません。ボトルネックにはなりません。NTFS ジャンクションに関連するオーバーヘッドは多少ありますが、このシナリオでは無視できる程度です。

データを物理的に SSD に移動し、ジャンクションをまったく使用しないことでオーバーヘッドをなくすことができます (これが質問の中心的な懸念事項のように思えます) が、その違いを測定できるかどうかは疑問です。

ジャンクションはどこに保存され、キャッシュされますか?

ジャンクションのタイプ再解析ポイントこれらはすべて$Extend\$Reparse メタファイル(もう 1 つの有名なメタファイルは です$MFT)。

ファイルまたはディレクトリに再解析ポイントが関連付けられている場合、NTFS は$Reparse再解析ポイントの名前の付いた属性を作成します。この属性には再解析コードとデータが格納されます。NTFS がボリューム上のすべての再解析ポイントを簡単に見つけられるように、名前の付いたメタデータ ファイルには、再解析ポイント \$Extend\$Reparseファイルとディレクトリの MFT エントリ番号を関連する再解析ポイント コードに結び付けるエントリが格納されます。NTFS は、インデックス内の MFT エントリ番号でエントリを並べ替えます$R

ソース:Win2K NTFS の内部、パート 1 (Mark Russinovich 著)

図を再解析する

再解析プロセス

ソース:Win2K NTFS の内部、パート 1 (Mark Russinovich 著)

ジャンクションは MFT に保存され、MFT はキャッシュされるというコメントがありました。 さて、ジャンクションがどこに保存されるかがわかったら、キャッシュの主張を裏付ける信頼できるソースが必要になりますが、それを見つけることができませんでした。

だから分かりませんが、それは問題ではないと思います。

クロスディスクジャンクションによってパフォーマンスが低下したという文書化されたシナリオはありますか?

はい、ARFP遭遇した問題こんな感じです。彼は小さなファイルの一括削除のベンチマークをしていましたが、操作がジャンクションを介して実行されると、制限要因はIO(予想通り)ではなくCPUになりました。このベンチマークは、GitHub

関連情報