Далее. NTFS работает себе и работает, и всё-таки фрагментируется - даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов - второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем очень интересным способом: сначала заполняются большие дырки, потом маленькие, т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):

16 - 16 - 16 - 16 - 16 - [скачек назад] - 15 - 15 - 15 - [назад] - 14 - 14 - 14 1 - 1 - 1 -1 - 1 .

Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более крупные куски свободного пространства.

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

Смысл в сего этого вступления в пояснении того простого факта, что никак нельзя сказать, что NTFS препятствует фрагментации файлов. Наоборот, она с радостью их фрагментирует. Фрагментация NTFS через пол года работы доведет до искреннего удивления любого человека, знакомого с работой файловой системой. Поэтому периодически приходится запускать "дефрагментатор". Но на этом все наши проблемы не заканчиваются, а, увы, только начинаются .

Средства решения?

В NT существует стандартная API дефрагментация, обладающая интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16-ти кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16-ти кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:

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

Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) "временно занятое пространство", дополняющее его по размеру до кратности 16-ти кластерам.

При попытке как-то неправильно ("не кратно 16-ти") переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не перемещается . Тем не менее, всё пространство действия щедро рассыпается "временно занятым пространством".

"Временно занятое пространство" служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты.

Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке):

Вынимание файлов из MFT зоны. Не специально - просто обратно туда их положить не представляется возможным. Безобидная фаза, и даже в чем-то полезная.

Дефрагментация файлов - безусловно, полезный процесс, правда, несколько, осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.

Дефрагментация MFT, файла виртуальной памяти (pagefile.sys) и каталогов - возможна через API, только в Windows 2000 и Windows XP, иначе - при перезагрузке, отдельным процессом, как в старом 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 кластеров.

Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации "новоприбывающих" файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически.

Часть 3. Что выбрать?

Любая из представленных ныне файловых систем уходит своими корнями в глубокое прошлое - еще к 80-м годам. Да, NTFS, как это не странно - очень старая система! Дело в том, что долгое время персональные компьютеры пользовались лишь операционной системой DOS, которой и обязана своим появлением FAT-а. Но параллельно разрабатывались и тихо существовали системы, нацеленные на будущее. Две таких системы, получившие всё же широкое признание - NTFS, созданная для операционной системы Windows NT 3.1 еще в незапамятные времена, и HPFS - верная спутница OS/2.

Внедрение новых систем шло трудно - еще в 1995 году, с выходом Windows 95, ни у кого не было и мыслей о том, что нужно что-то менять. FAT получил второе дыхание посредством налепленной сверху заплатки "длинные имена", реализация которых там хоть и близка к идеально возможной без изменения системы, но всё же довольно бестолкова. Но в последующие годы необходимость перемен назрела окончательно, поскольку естественные ограничения FAT-а стали давать о себе знать. FAT32, появившаяся в Windows 95 OSR2, просто сдвинула рамки - не изменив сути системы, которая просто не дает возможности организовать эффективную работу с большим количеством данных.