"Быстро, дешево и хорошо — из этих трех вещей нужно всегда выбирать две. Если быстро и дешево, это никогда не будет хорошо. Если это дешево и хорошо, никогда не получится быстро. А если это хорошо и быстро, никогда не выйдет дешево. Но помни: из трех все равно придется всегда выбирать два." (Том Уэйтс)
"Если ваша компания не заинтересована в дизайне, она бессмысленна. Все имеет форму. И если что-то имеет форму, значит, оно имеет смысл. Вы вынуждены создавать дизайн. Но дизайн – это не только форма. Дизайн – это также функциональность, себестоимость, стиль жизни и ее продолжительность." (Кьелл Нордстрем и Йонас Риддерстрале)
"Главное для дизайнера — создавать такие вещи, которые радуют его самого, чтобы работа приносила удовлетворение, а сотрудничество с заказчиком — удовольствие. Нужно понять, что хочет заказчик, и соединить это со своими желаниями и возможностями. Чтобы создать что-то выдающееся, нужен энтузиазм обоих." (Хорхе Пенси)

Фрагментация 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 теми средствами, которые сложились исторически.