Фрагментація NTFS

Малобюджетні сайти.

Просування веб-сайту.

Фрагментація NTFS

Або факти, які Diskeeper 'забуває' нам розповісти.

На самому початку стверджувалося, що NTFS не схильна до фрагментації файлів. Це виявилося не зовсім так, і твердження змінили – NTFS перешкоджає фрагментації. Виявилося, що це не зовсім так. Тобто вона, звичайно, перешкоджає, але толк від цього близький до нуля. Зараз вже зрозуміло, що NTFS - система, яка як ніяка інша схильна до фрагментації, що б не затверджувалося офіційно. Єдине що – логічно вона не дуже від цього страждає. Усі внутрішні структури побудовані в такий спосіб, що фрагментація не заважає швидко знаходити фрагменти даних. Але від фізичного наслідку фрагментації – зайвих рухів головок – вона, звісно, ​​не рятує. І тому – вперед і з піснею.

NTFS – дуже економна система. Розмір кластерів у ній розумно мінімальний - зазвичай це 4 кб (на стандартних зараз дисках десяток-другий гігабайт). Як відомо, система найсильніше фрагментує файли, коли вільне місце закінчується, коли доводиться використовувати дрібні дірки, що залишилися від інших файлів. Тут з'являється перша властивість NTFS, яка прямо сприяє серйозній фрагментації. Диск NTFS поділений на дві зони. На початку диска йде MFT зона - зона, куди росте MFT, Master File Table. Зона займає мінімум 12% диска, і запис даних у цю зону неможливий. Це зроблено для того, щоб не фрагментувався хоча б MFT. Але коли решта диску заповнюється - зона скорочується рівно вдвічі :). І так далі. Таким чином, ми маємо не один захід закінчення диска, а кілька. В результаті, якщо NTFS працює при диску, заповненому на близько 90% - фрагментаціяросте як шалена.

  • Попутне слідство - диск, заповнений більш ніж 88%, дефрагментувати майже неможливо - навіть API дефрагментації неспроможна переміщати дані до MFT зону. Може виявитися так, що ми не матимемо вільного місця для маневру.

Далі. NTFS працює собі і працює, і все-таки фрагментується. Цьому сприяє дивний алгоритм знаходження вільного місця - другий серйозний недогляд. Якщо файл пишеться великими шматками – все нормально. Але якщо файл повільно зростає - алгоритм такий: береться певний обсяг диска і заповнюється файлом до упору. Причому за цікавим алгоритмом: спочатку заповнюються великі дірки, потім маленькі. Тобто. типовий розподіл фрагментів файлу за розміром на фрагментованій NTFS виглядає так (розміри фрагментів): 16 - 16 - 16 - 16 - 16 - [стрибків назад] - 15 - 15 - 15 - [назад] - 14 - 14 - 14 . 1 - 1 - 1 -1 - 1. Так процес йде до найдрібніших дірок в 1 кластер, незважаючи на те, що на диску напевно є і набагато більші шматки вільного місця.

Можливо я забув написати щось ще. Сенс у цьому, що неможливо сказати, що NTFS перешкоджає фрагментації файлів. Навпаки, вона радо їх фрагментує. Фрагментація NTFS через півроку роботи доведе до подиву будь-якої людини, знайомої з роботою файловою системою. Тому доводиться запускати дефрагментатори. Але на цьому всі наші проблеми не закінчуються, а, на жаль, тільки починаються.

У NT існує стандартна дефрагментація API. Має цікаве обмеження для переміщення блоків файлів: за один раз можна переміщати не менше 16 кластерів (!), причому починатися ці кластери повинні з позиції, кратної 16 кластерів у файлі. Загалом операція здійснюєтьсявиключно по 16 кластерів. Наслідки:

  • У дірку вільного місця менше 16 кластерівне можна нічого перемістити(крім стиснутих файлів, але це тонкощі).
  • Файл, переміщений в інше місце, залишає після себе (на новому місці) "тимчасово зайняте місце", що доповнює його за розміром до кратності 16 кластерам.
  • При спробі якось неправильно ("не кратно 16") перемістити файл результат часто непередбачуваний. Щось округляється, щось просто не переміщається. Проте все місце дії щедро розсипається "тимчасово зайнятим місцем". Напевно, про нас дбають, щоб ми відстали від цього місця – щоб алгоритм дефрагментації не клинило. :)
  • "Тимчасово зайняте місце" звільняється через деякий час, зазвичай десь пів хвилини. Ги.

Тим не менш, логічно було б використовувати це API. Його й використовують. Тому процес стандартної дефрагментації з поправками на обмеженість API йде наступними фазами, не обов'язково в цьому порядку:

  • Виймання файлів із MFT зони. Не спеціально - просто назад туди їх покласти неможливо. Нешкідлива фаза, і навіть у чомусь корисна.
  • Дефрагментація файлів. Безумовно корисний процес, що дещо правда ускладнюється обмеженнями кратності переміщень - файли часто доводиться перекладати сильніше, ніж це було б логічно зробити з розуму.
  • Дефрагментація MFT, віртуалки (pagefile.sys) та каталогів. Можлива через API тільки в Windows2000, інакше - при перезавантаженні окремим процесом, як у Diskeeper-і.
  • Складання файлів ближче до початку – так звана дефрагментація вільного місця. Ось це воістину страшний процес.

Допустимо, ми хочемо покласти файли поспіль на початок диска. Кладемо один файл. Вінзалишає хвіст зайнятості доповнення до кратності 16. Кладемо наступний - після хвоста, звичайно. Через деякий час, після звільнення хвоста, маємо дірку

Хочеться висловити величезну подяку людині на ім'я Mark Russinovich (http://www.sysinternals.com/), яка надала громадськості .h та приклади використання інтерфейсу дефрагментації.

І насамкінець – програма fv виводить кількість фрагментів у файлах поточного каталогу, а з ключем /v [ім'я файлу] – список розмірів блоків (фрагментів) зазначеного файлу, у кластерах. Знак