HDD間のNTFSジャンクションポイントがボトルネックを引き起こす可能性はありますか?または、ジャンクションはメモリにキャッシュされますか?
具体的には、Steamを磁気HDDにインストールしたいと思います。これは、すべてのゲームがそこにインストールされることを意味します。 SSDを活用するために、アクティブにプレイしているゲームをHDD上のSteamのディレクトリからSSDにジャンクションポイントします。
これがパフォーマンスの問題を引き起こすのではないかと思っていました。ゲームがファイルにアクセスするたびに、HDDを読み取り、ジャンクションポイントを読み取り、SSDの新しいパスを解決してから、実際のファイルを取得する必要がありますか?それとも、OSがこのリダイレクトをキャッシュして、パフォーマンスの低下が最初に発生するだけになるのでしょうか。
ありがとう!
おそらくいいえ、それはボトルネックにはなりません。 NTFSジャンクションに関連するオーバーヘッドがいくつかありますが、シナリオでは無視できるはずです。
データをSSDに物理的に移動し、ジャンクションをまったく使用しないことでオーバーヘッドを取り除くことができますが(これは私にとってあなたの質問の中心的な関心事のようです)、違いを測定できるとは思えません。
ジャンクション はタイプです 再解析ポイント これらはすべて$Extend\$Reparse
に格納されます メタファイル (もう1つのより有名なメタファイルは$MFT
です)。
ファイルまたはディレクトリに再解析ポイントが関連付けられている場合、NTFSは再解析ポイント用に
$Reparse
という名前の属性を作成します。この属性は、再解析コードとデータを格納します。 NTFSがボリューム上のすべての再解析ポイントを簡単に見つけることができるように、\$Extend\$Reparse
という名前のメタデータファイルは、再解析ポイントファイルとディレクトリMFTエントリ番号を関連する再解析ポイントコードに接続するエントリを格納します。 NTFSは、$R
インデックスのMFTエントリ番号でエントリを並べ替えます。
ソース: Win2K NTFSの内部、マーク・ルシノビッチによるパート1
ダイアグラムの再解析
ソース: Win2K NTFSの内部、マーク・ルシノビッチによるパート1
ジャンクションはMFTに保存され、MFTはキャッシュされるというコメントがありました。さて、ジャンクションがどこに保存されているかがわかったら、キャッシングクレームをサポートするための信頼できるソースが必要になります。見つかりませんでした。
ですからわかりませんが、それは重要ではないと思います。
はい、 [〜#〜] arf [〜#〜] は issue のようになりました。彼は小さなファイルのバッチ削除のベンチマークを行っていました。操作がジャンクションを越えて実行されたとき、制限要因はもはやIO(予想どおり)ではなくCPUでした。このベンチマークについても詳細に説明しました。 GitHub 。