Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
WildGoblin
Я исходил из того факта, что NTFS не сильно теряет производительность при фрагментации менее 1%, а т.к. PD при записи если включена Exclusive OptiWrite fragmentation prevention и сам старается разместить файлы в один блок, то частота его автоматического вызова для дефрагментации больших томов (например у меня на сервере в RAID5 стоят шестнадцать SAS дисков Constellation ES2 по 2Tb в массивах по 6Тб) будет ниже, что уменьшит среднее время доступа к данным за счёт снижения системных накладных расходов. Расчёт оправдался - PD реже "вмешивается" в работу сервера, а диски (и так достаточно быстрые) работают на максимально возможной для себя скорости.
Если учитывать особенности механизма записи ФС, то PD легко можно настроить на оптимальный для любой задачи режим работы. Раньше, когда я впервые с ним столкнулся в его варианте для DEC Open VMS (она была исторически самой первой) у него подобных настроек ещё не было и там сама система запускала его при своём старте через крон что иной раз приводило к приличной (до 10 - 15 минут) задержке появления окна логона если диск был сильно забит данными.
И насчёт шаманства всё просто - NTFS умеет сообщать средний уровень своей фрагментации - статистические данные хранятся в MFT, а демон PD их считывает и проверяет наступления события "превышение порога фрагментации" и если это произошло, то управление передаётся драйверу PD, а уже он запускает механизм дефрагментации встроенный в NTFS.
Так что мы имеем классическую систему автоматического управления с обратной связью по событию "превышение порогового параметра".
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
Всего записей: 34379 | Зарегистр. 31-07-2002 | Отправлено: 04:23 23-11-2012 | Исправлено: Victor_VG, 12:04 23-11-2012 |
|
Или хотя бы hot-fix выпустили...
