Точка соединения NTFS с HDD на SSD, не вызовет ли это узких мест в производительности? (перемещение паровой игры)

1170
ddtemplar

Может ли точка соединения NTFS между жесткими дисками вызвать узкое место? Или соединение будет кешироваться в памяти?

В частности, я хочу установить Steam на магнитный жесткий диск. Это означает, что все игры будут установлены там. Чтобы извлечь выгоду из моего SSD, я соединю игры, в которые я активно играю, из каталога Steam на жестком диске в SSD.

Мне было интересно, если это приведет к снижению производительности. Каждый раз, когда игра обращается к файлу, нужно ли ей читать жесткий диск, читать точку соединения, определять новый путь на SSD, а затем получать истинный файл? Или это ОС кеширует это перенаправление, так что снижение производительности происходит только в первый раз?

Спасибо!

13
Определение точки соединения непосредственно сохраняется в ответственной записи MFT. Поскольку MFT кэшируется в памяти, я не ожидаю, что жесткий диск будет доступен при работе со связанным каталогом. Gene 9 лет назад 3
Спасибо! Тогда я не буду слишком беспокоиться об этом, если не начну замечать странные замедления. ddtemplar 9 лет назад 0
Даже если доступ к жесткому диску необходим для чтения точки соединения, он крошечный - считывание закончится почти сразу и должно произойти только один раз, поскольку оно будет кэшировано. Adambean 8 лет назад 2
Примечание с одной стороны: если вы устанавливаете приложение steam на SSD, вы все равно можете изменить место установки игры в steam без перехода. cybernard 8 лет назад 0

1 ответ на вопрос

5
Vlastimil Ovčáčík

Скорее всего нет, это не будет узким местом. С переходами NTFS связаны некоторые издержки, но в вашем сценарии они должны быть незначительными.

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

Где хранятся и кэшируются соединения?

Соединения - это тип точек повторного анализа, которые все хранятся в $Extend\$Reparse метафайле (другой более известный метафайл - это $MFT).

Если с файлом или каталогом связана точка повторной обработки, NTFS создает атрибут, названный $Reparseдля этой точки повторной обработки. Этот атрибут хранит код повторной обработки и данные. Чтобы NTFS могла легко найти все точки повторной обработки на томе, в файле метаданных с именем \$Extend\$Reparseхранятся записи, которые соединяют номера записей файла повторной обработки и каталога MFT со связанными кодами точек повторной обработки. NTFS сортирует записи по номеру записи MFT в $Rиндексе.

Источник: Inside Win2K NTFS, часть 1, Марк Руссинович

Диаграмма повторной обработки

Reparse process

Источник: Inside Win2K NTFS, часть 1, Марк Руссинович

Были комментарии, что соединения хранятся в MFT и что MFT кэшируется. Что ж, теперь, когда мы знаем, где хранятся соединения, мне понадобится надежный источник для поддержки утверждения о кешировании; который я не смог найти.

Так что я не знаю, но я не думаю, что это имеет значение.

Есть ли документированный сценарий, когда кросс-дисковый переход снижает производительность?

Да, ARF столкнулся с такой проблемой . Он тестировал пакетное удаление небольших файлов, и когда операция проводилась через соединение, ограничивающим фактором был уже не IO (как и ожидалось), а процессор. Этот тест также подробно обсуждался на GitHub .

Похожие вопросы