Дефрагментация NTFS

[Ajax]

2Dutchman
Это у тебя поди пол-винта свободно плюс один новый файл в месяц! <!--emo&:D-->[img]style_emoticons/<#EMO_DIR#>/biggrin.gif[/img]<!--endemo--> У меня постоянно свободны килобайты и вообще... Короче говоря, фрагментация - серьезная проблема!

2Maksimys
Я тут не модер, но ты не флуди.

[dAnIK SeNT]

2Dutchman
Аякс дело говорит. Когда среднее количество свободного места на винте - 500 килобайт... В те моменты, когда это количество увеличивается, делать дефрагментацию - жизненно важно <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

[Dutchman]

Ajax три гига из тридцати. Кол-во файлов месяц не замерял. Насколько я знаю, ХР сама оптимизацию делает, если ее в покое оставить на некоторое время. Впрочем, не проверял.

dAnIK SeNT Ajax
Маньяки вы. Издеваетесь над собой и беззащитным компьютером

[dAnIK SeNT]

2Dutchman
Сама ХР оптимизацию не делает. Проверял неоднократно <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->.

ЗЫ. Не мы такие, жизнь такая <!--emo&:D-->[img]style_emoticons/<#EMO_DIR#>/biggrin.gif[/img]<!--endemo-->
В настоящий момент свободно 25 из 200. Но это потому что я уже вот весь вечер сижу и чищу-чищу-чищу, режу-режу-режу... В конце недели 250 гигов свежих поступлений придёт - надо распинывать будет...

[Dutchman]

Кстати. Залез-таки в Ы-нет дабы освежить и углубить:
О вреде:
<!--QuoteBegin-журнал ксакеп+--><div class='quotetop'>QUOTE(журнал ксакеп)</div><div class='quotemain'><!--QuoteEBegin-->
При создании NTFS утверждалось, что она не подвержена фрагментации, хотя, как ты правильно понял, это - полный бред. Фрагментации подвержено даже ОЗУ, где механики не было и в помине. Просто, в отличие от FAT, она не так катастрофически сказывается на скорости - дают о себе знать вышеописанные навороты с резидентными файлами, небольшим размером кластера и индексированием атрибутов. Однако от физического перемещения головок жесткого диска это не спасает. Особо плачевно сказывается на быстродействии файловой системы фрагментация MFT.

Как было отмечено ранее, при приближении степени заполнения жесткого диска к 88%, размер зоны MFT уменьшается в два раза, и - далее со всеми остановками. Фактически на диске получается несколько заходов окончания диска. Не препятствует (скорее наоборот) фрагментации использование зашифрованных, сжатых и разреженных файлов. И даже сама логическая организации записи как бы 'старается' увеличить фрагментацию: сначала заполняются большие дырки, потом - маленькие. На этом веселье не заканчивается, скорее, наоборот:

Встроенное в ХР стандартное API дефрагментации позволяет перемещать за один раз не менее 16 кластеров. Начинаться эти кластеры должны с позиции виртуального номера кластера, кратной 16. Эдакое любимое число <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->. И все это - независимо от файловой системы. В результате 100% дефрагментация стандартными средствами ХР становится, проще говоря, невозможной. Лично, так сказать, убедиться в этом можно, запустив слепок стандартного дефрагментатора dfrg.msc (свойства диска - сервис - дефрагментация).

Ну а в ожидании, пока Microsoft исправит эту проблему, остается порекомендовать воспользоваться утилитами сторонних разработчиков, вроде Diskeeper.
<!--QuoteEnd--></div><!--QuoteEEnd-->

<!--QuoteBegin-статья+ про которую я говорил--><div class='quotetop'>QUOTE(статья @ про которую я говорил)</div><div class='quotemain'><!--QuoteEBegin-->В NT существует стандартное API дефрагментации. Обладающее интересным
ограничением для перемещения блоков файлов: за один раз можно перемещать
не менее 16 кластеров (!), причем начинаться эти кластеры должны с
позиции, кратной 16 кластерам в файле. В общем, операция осуществляется
исключительно по 16 кластеров. А из этого следует вот что:

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

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

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

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

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

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

Дефрагментация MFT, файла виртуальной памяти (pagefile.sys) и каталогов.
Возможна через API только в Windows2000, иначе - при перезагрузке,
отдельным процессом.

Складывание файлов ближе к началу - так называемая дефрагментация
свободного места. Вот об этом страшном процессе подробнее.

Допустим, мы хотим положить файлы подряд в начало диска. Кладем один
файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем
следующий - после хвоста, естественно. Через некоторое время, по
освобождению хвоста, имеем дырку размером менее 16 кластеров, которую
потом невозможно заполнить через API дефрагментации! В результате, до
оптимизации картина свободного места выглядела так: много дырок примерно
одинакового размера. После оптимизации - одна дыра в конце диска, и
много маленьких (менее 16 кластеров) дырок в заполненном файлами
участке. Какие места в первую очередь заполняются? Правильно,
находящиеся ближе к началу диска мелкие дырки менее 16 кластеров. Любой
файл, плавно созданный на прооптимизированном диске, будет состоять из
дикого числа фрагментов, что потребует очередной оптимизации диска уже
через неделю! Таким образом, имеется два примерно равнозначных варианта.
Первый - часто оптимизировать диск таким дефрагментатором, смирясь при
этом с дикой фрагментацией заново созданных файлов. Второй вариант -
вообще ничего не трогать, и смириться с равномерной, но гораздо более
слабой фрагментацией всех файлов на диске. Но есть еще один способ –
использовать дефрагментатор, который игнорирует API. На сегодняшний день
существует один такой дефрагментатор – Norton SpeedDisk 5.x для NT. Все
остальные дефрагментаторы при одноразовом применении просто вредны. Если
вы запускали его хоть раз - нужно запускать его потом хотя бы раз в
месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом и
состоит основная суть сложности фрагметирования и дефрагментирования
файлов.
<!--QuoteEnd--></div><!--QuoteEEnd-->

Промежуточный вывод. Пересказ мой далек от исходного варианта.

О проблемах при заполнении диска:

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->Диск NTFS поделен на две зоны. В начала диска идет MFT зона - зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается ровно в два раза. И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% - фрагментация растет как бешенная.

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

Далее. NTFS работает себе и работает, и всё таки фрагментируется - даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов - второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора.<!--QuoteEnd--></div><!--QuoteEEnd-->


До кучи из серии типс и трикс <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->:

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->Запустить процесс можно также из командной строки, вы будете лишены GUI, но процесс будет идти быстрее. Для этого в командной строке необходимо выполнить команду defrag.exe
<!--QuoteEnd--></div><!--QuoteEEnd-->

Глобальный вывод: нефиг диск до упора забивать.
Следствие: это не жизнь такая, это аниме много <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->
Из следствия дилемма: когда только отсматривать успеваешь?

[MAPA3bM]

[flame]
Вот так. Решили мокрософты переплюнуть юниксовые ФС - и в очередной раз облажались. Честно говоря, я о NTFS был лучшего мнения..
[/flame]

[dAnIK SeNT]

Dutchman
Отсматривать даже Аякс не успевает, уж на что он маньяк...

2MAPA3bM
Дык... NTFS сравнивать, скажем, с ReiserFS даже смысла нет.

2All
Проводил эксперимент. Дефрагментировал диск (ессно, при помощи VoptXP, поэтому никаких "зазоров" между файлами не осталось) с дефрагментацией свободного места. Потом удалил несколько файлов из его начала (появились дыры).
Скопировал туда новый файл при помощи Total Commander'а. Он целиком разместился в "большой дыре" в конце диска, дыры в начале остались незаполненными. Удалил файл.
Скопировал туда тот же файл с помощью Windows Explorer. Он аккуратно заполнил все дыры от начала диска.
Причины? Total выделяет сразу весь объём, необходимый для копирования файла, соответственно, файловая система может подобрать подходящий непрерывный кусок.
Explorer дополняет файл по мере копирования, соответственно система, не зная, каким может быть окончательный размер файла, выделяет по мере поступления данных. Т.е. все дыры, большие или равные объёму "шага выделения" заполняются в порядке их следования на диске.
Выводы? Пользуйтесь нормальным файловым менеджером.

[hoopoe]

стоп, насколько я знаю как раз эксплорер выделяет сразу все место - сам видел... (XP + SP1)

[dAnIK SeNT]

2hoopoe
Странная фигня. Нифига у меня не выделял.
Впрочем, эксперимент давно проводил. Может ещё даже когда на вынь2000 сидел - не помню.

[Strike]

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->Дык... NTFS сравнивать, скажем, с ReiserFS даже смысла нет.<!--QuoteEnd--></div><!--QuoteEEnd-->
Пусть это и офтоп, но нельзя ли вкратце о преимуществах ReiserFS над NTFS и FAT32?

[Night Angel]

2Strike
А я на слово верю. Дефрагментировать не надо в принципе. Журналируемость. Аудит...

[Strike]

2Night Angel
Мне просто интересны некоторые подробности. Я сам под Никсами не сидел, хотя собираюсь, вот и решил начать ознакомление с ФС.

[maxovt]

2Strike
Могу маленькую статейку скинуть на мыло по журналируемым ФС в Linux...

[Strike]

2maxovt
Cкинь если не трудно на skynet[at]newmail.ru

[Ajax]

2Night Angel
Вот это как раз неверно... Сколько раз наблюдал реальное и неслабое ускорение работы системы в целом после дефрагментации винта... Представь себе винт объемом 9 гиг, который с 90-х гдов не дефрагментировали!!! Программы чел меняет каждый день...

В общем, юзвери иногда аж пыхтят от удовльствия после дефрага %)