Особенности дефрагментации NTFS

Hard Links

Эта возможность была в NTFS с незапамятных времен, но использовалась очень редко - и тем не менее: Hard Link - это когда один и тот же файл имеет два имени (несколько указателей файла-каталога или разных каталогов указывают на одну и ту же MFT запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt: если пользователь сотрет файл 1, останется файл 2. Если сотрет 2 - останется файл 1, то есть оба имени, с момента создания, совершенно равноправны. Файл физически стирается лишь тогда, когда будет удалено его последнее имя.

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

Symbolic Links (NT5)

Гораздо более практичная возможность, позволяющая делать виртуальные каталоги, виртуальные файлы - ярлыки. (Виртуальные диски в DOSе делаются командой subst.) Применения достаточно разнообразны: во-первых, упрощение системы каталогов. Если вам не нравится каталог Documents and settings\Administrator\Documents, вы можете прилинковать его в корневой каталог - система будет по-прежнему общаться с каталогом с дремучим путем, а вы - с гораздо более коротким именем, полностью ему эквивалентным. Для создания таких связей можно воспользоваться программой junction (junction.zip (15 Kb), 36 кб), которую написал известный специалист Mark Russinovich (http://www.sysinternals.com/). Программа работает только в NT5 (Windows 2000), как и сама возможность.

Шифрование (в Windows 2000 – EFS)

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

Рассмотрим один достаточно интересный вопрос - фрагментация и дефрагментация NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в Windows NT, никак не может быть названа удовлетворительной. В самом начале утверждалось, что NTFS не допускает фрагментации файлов. Это оказалось не совсем так, и утверждение сменили - NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю... Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Важно только то, что логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации – лишних движений головок – NTFS, конечно, не спасает.

Как так получилось? Как известно, система сильнее всего фрагментирует файлы, когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Что получается в NTFS с такой ситуации?

Диск NTFS поделен на две зоны. В начала диска идет MFT зона - зона, куда растет MFT, Master File Table. Зона занимает при форматировании 12% диска, и запись данных в эту зону при нормальной работе невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается ровно в два раза. Это может произойти и повторно. Таким образом, мы сталкиваемся с ситуацией заполнения диска несколько раз. Фрагментация файлов при этом усиливается. В результате диск, заполненный более чем на 88%, дефрагментировать почти невозможно - даже API дефрагментации не может перемещать данные в MFT зону, следовательно, программе дефрагментации некуда переписать данные даже временно.

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

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

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

Теперь рассмотрим, что получается в результате складывания файлов ближе к началу (так называемая дефрагментация свободного места).

Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров, которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров. Любой файл, плавно созданный на прооптимизированном диске, будет состоять из большого числа фрагментов. Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с сильной фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.

Существовал всего один дефрагментатор, который игнорировал API дефрагментации и работал напрямую - Norton Speeddisk 5.0 для NT4. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере, уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места.

К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно плодит дырки <16 кластеров. Так что как только появится (если еще не появился) - так сразу надо устанавливать Speeddisk для W2k.

Дата добавления: 2014-12-07