На самому початку стверджувалося, що 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. Кладемо наступний - після хвоста, природно. Через деякий час, зі звільнення хвоста, маємо дірку <16 кластерів розміром. Яку потім неможливо заповнити через API дефрагментації! В результаті, до оптимізації картина вільного місця виглядала так: багато дірок приблизно однакового розміру. Після оптимізації - одна дірка в кінці диска, і багато маленьких <16 кластерів дірок у заповненому файлами ділянці. Які місця в першу чергу заповнюються? Правильно, що знаходяться ближче до початку диска дрібні дірки <16 кластерів ... Будь-який файл, плавно створений на прооптімізірованном диску, буде складатися з дикого числа фрагментів. Так, диск потім можна оптимізувати знову. А потім ще раз .. і ще .. і так - бажано щотижня. Маячня? Реальність.

Таким чином, є два приблизно рівнозначних варіанту. Перший - часто оптимізувати диск таким дефрагментатором, упокорюючись при цьому з дикою фрагментацією заново створених файлів. Другий варіант - взагалі нічого не чіпати, і змиритися з рівномірною, але набагато слабшою фрагментацією всіх файлів на диску.

Поки є один дефрагментатор, який ігнорує API дефрагментації і працює якось більш безпосередньо - Norton Speeddisk 5.0 для NT. Коли його намагаються порівняти з усіма іншими - Diskeeper, O & O defrag, тощо - Не згадують цього головного, найважливішого, відмінності. Просто тому, що ця проблема ретельно ховається, принаймні вже точно не афішується на кожному кроці. Speeddisk - єдина на сьогоднішній день програма, яка може оптимізувати диск повністю, не створюючи маленьких незаповнених фрагментів вільного місця. Варто додати також, що стандартне API не може дефрагментувати томи NTFS з кластером більше 4 Кбайт - а SpeedDisk, як і раніше, може.

На жаль, в Windows 2000 засунули дефрагментатор, який працює через API, і відповідно плодить дірки <16 кластерів. Так що як тільки з'явиться (якщо вже не з'явився) - так відразу треба качати Speeddisk для W2k. Як деякий висновок з усього цього - всі інші дефрагментатори при одноразовому застосуванні просто шкідливі. Якщо ви запускали його хоч раз - потрібно запускати його потім хоча б раз на місяць, щоб позбавиться від фрагментації новопрібивающіх файлів. У цьому основна суть складності дефрагментації NTFS тими засобами, які склалися історично.