Точка з’єднання NTFS від жорсткого диска до SSD, чи спричинить це вузьке місце? (переїзд парової гри)

Чи може точка з'єднання NTFS між жорсткими дисками викликати вузьке місце? Або перехід запам'ятовується в пам'яті?

Зокрема, я хочу встановити Steam на магнітний жорсткий диск. Це означає, що там будуть встановлені всі ігри. Щоб отримати перевагу від мого SSD, я вкажу на ігри, в які активно граю, з каталогу Steam на жорсткому диску до SSD.

Мені було цікаво, чи це спричинить проблеми з продуктивністю. Кожен раз, коли гра отримує доступ до файлу, чи потрібно читати жорсткий диск, читати точку з'єднання, вирішувати новий шлях на SSD, а потім отримувати справжній файл? Або ОС буде кешувати це перенаправлення, тож покарання за продуктивність вдаряється лише в перший раз?

Спасибі!

— ddtemplar
джерело

Визначення точки з'єднання безпосередньо зберігається у відповідальному записі MFT. Оскільки MFT зберігається в кеш-пам'яті, я не очікував би доступу до жорсткого диска під час роботи з пов'язаним каталогом.

— Гена

Спасибі! Я не буду надто переживати про це, якщо тільки не почну помічати дивні уповільнення.

— ddtemplar

Навіть якщо до жорсткого диска потрібно було отримати доступ, щоб прочитати точку з’єднання, воно крихітне - зчитування закінчиться майже одразу, і це має відбутися лише один раз, коли воно буде кешоване.

— Адамбей

Одна сторона Примітка: Якщо ви встановите додаток для пари на SSD, ви все одно можете змінити місце встановлення гри всередині пари без стику.

— cybernard

Швидше за все, ні, це не буде вузьким місцем. З переходами NTFS є деякі накладні витрати, але у вашому сценарії це повинно бути незначним.

Ви можете позбутися від накладних витрат, фізично перемістивши дані на SSD і зовсім не використовуючи переходи (що, здається, є головним питанням вашого питання до мене), але я сумніваюся, що ви могли б виміряти різницю.

Де зберігаються та кешуються стики?

З'єднання - тип точок повторного аналізу, які зберігаються у $Extend\$Reparse метафайлі (ще один відомий метафайл - це $MFT).

Коли файл або каталог пов'язаний з ним точкою повторного аналізу, NTFS створює атрибут, названий $Reparseдля точки повторного аналізу. Цей атрибут зберігає код перезапису та дані. Так що NTFS може легко знаходити всі точки повторного розбору на томі, файл метаданих з назвою \$Extend\$Reparseзберігає записи, які з'єднують файл точки перезавантаження та номери вхідних номерів MFT до пов'язаних з ними кодів повторного аналізу. NTFS сортує записи за номером запису MFT в $Rіндексі.

Джерело: Всередині Win2K NTFS, Частина 1 Марка Русиновича

Діаграма повторного аналізу

Джерело: Всередині Win2K NTFS, Частина 1 Марка Русиновича

Були коментарі, що переходи зберігаються в MFT і що MFT є кешованим. Ну а тепер, коли ми знаємо, де зберігаються з'єднання, я б зажадав надійного джерела для підтримки заявки на кешування; яких я не міг знайти.

Тому я не знаю, але не думаю, що це має значення.

Чи є задокументований сценарій, коли перехресне з'єднання диска знижує продуктивність?

Так, ARF зіткнувся з таким питанням . Він проводив тестування пакетного видалення невеликих файлів, і коли операція проводилася через з'єднання, обмежуючим фактором був вже не IO (як очікувалося), а процесор. Цей еталон також детально обговорювався на GitHub .

— Властиміл Овчачик
джерело