Вопрос по дефрагментации раздела под NTFS

[alec1]

Цитата:



но раздел Хочу Все Знать предназначен для начинающих



У меня просто вызвало затруднение, в какой раздел адресовать свою тему. Дабы не нафлудить и не прооффтопить, выбрал такую нейтральную. Впредь, буду бороться с ленью.

[Blast]

alec1, а я никогда никакими утилитами не чистил реестр на компьютере под управлением Windows XP SP1, потом SP2 и никаких вообще, а уж тем более "дичайших" глюков не имею более трех лет. И уж тем более я не могу доверить такую задачу программе, которая делает что-то чего я не знаю досконально. Программы разные есть - и хорошие и не очень, но ни одна из них не может учитывать всех особенностей всего софта и настроек системы.



Так что вот так

[Severny]

Я тоже не пользуюсь чистильщиками и т.п. Винда у меня начинает глючить и лагать спустя некоторое время, но никак не по вине Microsort, а только по моей собственной. Меня это особо не волнует, т.к. восстановить чистую систему из образа 5 минут, а софт я стараюсь использовать полностью от ОС независящий, чтобы с переустановкой не париться и данные не терять при крахе.

[Vadikan]

rizz, не надо больше флудить, ок?

[detrin]

Цитата rizz:



ну хочешь выиграть 10% по времени доступа к винту сиди и четыре часа смотри как дефрагментируется 240Гб, проще оперативки докинуть и винт быстрый поставить, куда больше толку будет..

»

Часто приходится иметь дело с базой шаблонов, всего около 30 папок, в каждой папке от 500 до 1500-2000 файлов. Причем файлы часто изменяются. Если долго диск не дефрагментировать, то папка может открыватся секунд 10, что через проводник, что через Тотал... Так о каких 10% выигрыша во времени идет речь?



А вообще дефрагментация винта имхо дело добровольное. Не все же ежедневно пользуются активно компьютером, кто-то может раз в месяц его включает. Проще говоря если устраивает скорость работы винта, то зачем его дефрагментировать?

[Michael]

Немного не в тему, но тоже о дефрагментации и скорости.

В свое время статью видел, вроде в Хакере. Смысл в том, что изначально система резервирует под MFT то ли 12,5%, то ли 15% от общего размера логического диска в области минимального времени доступа. До тех пор, пока свободное место на логическом диске не станет меньше зарезервированного, в эту область пишется только MFT. Потом - все подряд, соответственно при этом MFT размазывается по всему диску по принципу "где есть свободное место", а следовательно - увеличивается время доступа к данным.

При этом родной дефрагментатор устроен таким образом, что если MFT размазана, то обратно, в область с минимальным временем доступа, ее уже не собрать. Выход - либо format, либо сторонний софт.

[kim-aa]

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



- NTFS как любая файловая система любит упорядоченность данных, что в первую очередь связанно с тем что скорость доступа жесткого диска, к последовательным данным, на порядок выше чем к random ( распределенным по диску по какому либо закону). Опять же при последовательном чтении нужно осуществлять меньше операций I/O.



- NTFS более сложная файловая система чем FAT, что несет как плюсы так и минусы. Не вдаваясь в подробности скажу что

если данные расположены не последовательно, преимущество в скорости поиска имеет NTFS.

При последовательном чтении преимущества в скорости имеет FAT32, т.к. она осуществляет меньше системных операций, в частности не проводит проверку на безопасность.

FAT32 пишет всегда быстрее, т.к. журналирование отсутствует как класс. Естественно расплатой за это является меньшая устойчивость. Так же размер максимального файла в FAT32 по нынешним меркам невелик, однако в высоконагруженных серверных системах архитектуры Win32, размер файлов данных проектируется в 2 ГБ, т.е. влияния теоретический максимум не оказывает.



-NTFS имееет преимущество в сильно фрагментированных условиях перед FAT32, т.е. скорость доступа падает не так катастрофически.



--------------------------------------------------------------------------------------------

Что из всего этого следует:

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

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

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

-- Так же вы выигрываете в устойчивости системы в целом, т.е. даже если системный раздел уничтожен, скажем злым вирусом или кривыми руками, - данные остаются в целости. Или безбожно пухнущий TMP каталог, не вгонит систему в ступор.



Однако, как любое сложное осмысленное действие, разбиение жесткого диска на специализированные разделы, требует прикидочных расчетов. Правда в инструкциях по инсталляции либо серьезного ПО, либо Unix систем, все это есть.

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

--------------------------------------------------------------------------------------------

В настоящий момент это может быть не актуально, однако лет так 5-7 назад, разделы выделяемые для TMP-файлов, и SWAP- рекомендовали размещать вообще на FAT16 разделах, вся файловая таблица коих со свистом влетает в кэш любого компьютера.

(Для справки - операционная ситема Sun Solaris, в быстродействии которой вроде бы сомневаться не приходиться, хранит TMP-данные в Swap-разделе.)

[ShaddyR]

Цитата kim-aa:



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

Вопрос по дефрагментации раздела под NTFS

хм.. как то потерял логику рассуждения... Нолик не пропустил часом в последней цифре?

[aset]

Я тоже за дефрагментацию, но специальными программами для этого

кстати насчет чистки реестра я использую две программы это Reg Organizer и Ccleaner


Цитата Blast:



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

Вопрос по дефрагментации раздела под NTFS

а я наоборот как раз таки если бы знал бы досконально то сам бы чистил а так я доверяю тем кто разбирается лучше меня т.е. проге и глюков потом не замечено увеличивается производительность

хотя уважаемый Blast прав программы бывают разные после одной из них чуть виндоус не слетел не мог зайти под админом и по мелочи

[Blast]

Цитата aset:



после одной из них чуть виндоус не слетел

Вопрос по дефрагментации раздела под NTFS

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

Службы - Почта Windows

последствия, это пример, "чистильщик" считает, что какой-то параметр/раздел реестра вовсе не нужен, а я, допустим, пользуюсь программой, которой этот "ненужный" параметр необходим для работы
Цитата aset:



если бы знал бы досконально то сам бы чистил

Вопрос по дефрагментации раздела под NTFS

от чего? все так любят чистить многострадальный реестр
Цитата aset:



увеличивается производительность

Вопрос по дефрагментации раздела под NTFS

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