Вход

Просмотр полной версии : Насколько вредна дефрагментация?


Trendcatcher
17.07.2009, 21:24
Такой вопрос, может ли дефрагментация существенно сократить срок службы жд, если проводить ее допустим раз в месяц на жд в который ежедневно копируются и с которого удаляются тысячи файлов разного размера?

KR_AndR01d
17.07.2009, 21:33
Вобще то харды которые постаянно дифрагментируют дольше живут.

Toor
17.07.2009, 21:35
Такой вопрос, может ли дефрагментация существенно сократить срок службы жд, если проводить ее допустим раз в месяц на жд в который ежедневно копируются и с которого удаляются тысячи файлов разного размера?
Файловый сервер? NTFS, разумеется?

Смотря какими средствами проводить дефрагментацию... ЕМНИП, Марк Руссинович по этому поводу не одну статью написал, да и программулек наделал ;)

А так, да, вредит она неплохо... Особенно если требуется восстановление данных.

Valgaav
18.07.2009, 11:33
Раз в месяц? Чет многовато в год то получается:)
Смысла то особого не будет, ладно там раз в полгода, хотя бы.

DOGOR67
18.07.2009, 12:48
Дефрагментация удлиняет жизнь головки харда на несколько порядков, меньше будет носится по всей поверхности.

Uncle_L
18.07.2009, 15:27
Дефрагментация удлиняет жизнь головки харда на несколько порядков, меньше будет носится по всей поверхности.

Головке, строго говоря, плевать на дефрагментацию, поскольку "по всей поверхности" она все же не носится (над поверхностью - да). А вот время доступа к файлам может и сократиться.

Весёлый Молочник
18.07.2009, 18:05
Если совсем не хотите дефрагментировать (всегда дефрагментацию считал благом), ставьте нормальные файловые системы для серверов файловых.

Будь то ZFS, ext3,4, reizerfs.

Vitald
18.07.2009, 19:14
Дефрагментация – польза или вред?

На самом деле вопрос можно поставить даже шире. Была ли вообще данная проблема актуальна где-либо за пределами мира DOS и ее "производных" (включая Windows 95/98/Me)? Дать однозначный и исчерпывающий ответ не так-то просто. Не помогут никакие тестирования файловых систем и программ-дефрагментаторов -- в лабораторных условиях очень сложно воссоздать реальные рабочие ситуации, да еще и характерные для различных областей применения компьютеров. Полагаться стоит лишь на собственный опыт, трезвый взгляд на вещи и знания конструктивных особенностей ОС, файловых систем, и, как ни странно, -- аппаратного обеспечения. Начнем, пожалуй, с небольшого экскурса в историю двух "параллельных" миров -- IBM PC и Apple Macintosh.


Миры, в которых мы живем. Или, точнее, жили

Для начала рассмотрим более "взрослый" и дорогой мир Apple до эпохи G3. Что мы видим? Два ключевых момента, на которые стоит обратить внимание, -- это SCSI и HFS (особенно HFS+).

Одна из функций нормальных SCSI-контроллеров -- буферизация команд (Command Queuing) с возможным изменением порядка их исполнения, а также оптимизация хода головок накопителя. Говоря простым языком, когда контроллеру приходят команды на чтение/запись секторов с линейными номерами 2000, 1000, 3000, он исполнит их в той последовательности, которая наиболее удобна при текущем положении головок (например, 1000, 2000, 3000).

Возможно, некоторым читателям покажется, что таким образом SCSI-контроллер берет на себя часть функций дисковой подсистемы ОС. Однако горькая правда состоит как раз в том, что буферизация команд и данных (дисковый кэш, не путать с файловым) должна быть задачей именно контроллера, но часто перекладывается на ОС -- ради поддержки аппаратуры без соответствующих возможностей и "интеллекта". Всему виной некоторый сдвиг представлений в области операционных систем. Возьмем, к примеру, идею BIOS (firmware) как средство абстрагирования от подробностей функционирования оборудования и освобождения ОС от лишнего багажа драйверов. Вроде бы разумная идея, но, скажем, Windows 9x/2000/XP в вопросах ввода/вывода на BIOS не полагается. Да и любая другая операционная система, работающая в защищенном режиме процессоров семейства x86, фактически обречена на подобное положение -- использовать BIOS за пределами реального режима нецелесообразно, особенно в плане производительности.

Файловые системы HFS/HFS+ интересны нам постольку, поскольку их программные реализации также располагают неким "интеллектом", ответственным за снижение степени фрагментации. После года интенсивной ежедневной работы на машине Apple Macintosh в области полиграфии, где файлы отличаются как большим разнообразием размеров, так и постоянно изменяемым содержимым, степень фрагментации файловой системы HFS+ оставалась незначительной, а производительность (субъективно) не падала вовсе. Программа-дефрагментатор на этой машине была запущена единственный раз -- из любопытства, а никак не по необходимости.

Теперь посмотрим на рынок "массовых ПК" того (а в какой-то мере и нынешнего) времени: не обремененные "интеллектом" MFM-, RLL- и IDE-контроллеры, вполне оправданно на тот момент "заточенные" под однозадачные ОС путем отсечения излишней функциональности, присущей SCSI. Файловые системы, спроектированные скорее с упором на простоту реализации, нежели на эффективность работы. Экстенсивное развитие как аппаратного, так и программного обеспечения (увеличение разрядности, емкости, пропускной способности, но не архитектуры и алгоритмов).

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

На данный момент, разумеется, заметен некоторый "интеллектуальный ренессанс" и в мире PC -- то, что было "выброшено" раньше, начинает изобретаться заново. Стандарт ATA/ATAPI, например, все больше походит на "старичка" SCSI, происходит постепенное избавление от примитивных файловых систем FAT16/32 (справедливости ради нужно отметить, что их периодически пытались подправить в конкретных реализациях, скажем VFAT, но больших дивидендов это не приносило). Возможно, подобная "эволюционная петля" выглядит неплохо с финансовой точки зрения, но не с точки зрения пользователей.


День сегодняшний

А что происходит в мире многозадачных и многопользовательских ОС?

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

Однако в многозадачной среде характер работы с накопителями даже не "пахнет" детерминизмом. В середине чтения одним процессом одного файла, другому процессу вполне может понадобиться другой (не исключено, что и на противоположном конце диска). Соответственно не исключена ситуация, когда фрагментация окажется как раз во благо. Не случайно в среде администраторов Unix достаточно давно бытует не совсем ортодоксальное мнение о том, что фрагментация файловой системы порядка 25% немного повышает производительность при одновременной работе нескольких приложений, интенсивно и хаотично использующих дисковую подсистему.

Однако, кроме приведенных теоретических размышлений, существуют и практические исследования. В частности, их проводила достаточно авторитетная организация NSTL (National Software Testing Labs). Вроде бы ее отчеты однозначно свидетельствуют в пользу дефрагментации -- во всяком случае для Windows NT/2000/XP/2003 и NTFS. В одном из них даже приводятся результаты некоторых замеров производительности на основе приложений для серверов и рабочих станций. Чаще всего упоминаются "Excel Benchmark", "Outlook Benchmark" -- т. е. "однозадачные" тесты, не дающие, как говорилось выше, адекватной картины.

Встречается также "Exchange Benchmark", один раз упоминается "SQL Server test". По результатам исследований Outlook/Exchange прогнозируется прирост быстродействия от 5,9% до 55,6%. Касательно серверных тестов вообще приведена довольно размытая фраза: "Дефрагментация на сервере улучшила производительность на 80%. Для SQL-сервера, в некоторых случаях, эффект достигал 100%". К сожалению, не приводится ни методика тестирования, ни даже какой именно показатель подразумевается под термином "производительность сервера".


Выводы

Итак, что мы имеем в результате? Автор может предложить лишь собственное субъективное мнение, которое ни в коем случае не претендует на звание истины.

Сегодня уже есть целый ворох дефрагментаторов для различных ОС и файловых систем и регулярно появляются новые. Собственно поводом к написанию данной статьи послужил выпуск программы O&O Defrag Linux. Конечно, судить о конкретных достоинствах и недостатках по бета-версии некорректно, но, как мы попытались объяснить выше, вопрос стоит гораздо шире -- зачем вообще нужен дефрагментатор в системе, где выгода от его использования практически неуловима? Да, дефрагментация и в Linux может оказаться полезной в случае однопользовательской "однозадачной" настольной системы, особенно работающей с потоковыми данными. Но даже в этом случае вполне можно положиться на собственные механизмы "умной" файловой системы, со своей стороны помогая ей избегать фрагментации: оставлять достаточно свободного места на диске, хранить редактируемые данные в отдельном разделе и пр.

Подобные программы существуют постольку, поскольку на них есть спрос. Спрос же частично объясняется тем, что пользователи привыкли к тому, что подобные приложения необходимы для нормальной работы компьютера. Кроме того, некоторым подсознательно нравится, когда умное (с их точки зрения) ПО сообщает, что с компьютером все в порядке. Уровень интеллекта и диапазон возможностей среднего современного дефрагментатора значительно ниже, чем у аналогичной разработки эпохи DOS (кто-то вспомнит старый добрый Norton SpeedDisk и будет прав). Сегодня подобные программы (отнюдь не только дефрагментаторы) существуют больше как антидот от болезней пользователя, нежели компьютера.

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



http://itc.ua/node/15117/
ITC.UA, Алексей Матяшов, 14 октября 2003 г.

House
18.07.2009, 20:57
а я вот уже не верю в помощь дефрагментации.
Как всякое устройство хард имеет лимиты на количество движений головки, запись и чтение магнитной поверхности.
так что ИМХО дефрагментация идёт лесом и так ОС и другие проги не дают харду спокойно крутить свой диск =)

З.Ы. файловая система знает где и куда записала файл =) и на всякие долисекунды я не обращаю внимания. человек может заметить миг, который длится не более 1/24 секунды =).

HoMeR
18.07.2009, 22:00
За свою 8летнию практику работы с компьютерами, мое имхо я за дефрагментацию, на рабочих машинах (да и у меня дома) значительно на взгляд прибавки в загрузке приложений и т.д. и т.п. опять же это всего лишь мое имхо, а почему я так считаю обьяснять долго и лень :)

Jinc
18.07.2009, 23:03
лучшая прога для дефрагментации нтфс на ващ взгляд?

Весёлый Молочник
19.07.2009, 08:41
Да они все одинаковые. Кто то быстрее кто то медленее. Но они все используют Программа основана на стандартном дефрагментационном API от Microsoft, как и другие коммерческие решения.

Мне нравится вот эта (http://soft.ya1.ru/folder.php?id=1649).

Весит 100 кб, быстра, проста, надежна. Можно поставить вместо заставки.

Так же рекомендую почитать интервью (http://linux.ya1.ru/blog/topic/Interv-yu-s-Valeri-Avroroy---razrabotchikom-faylovih-sistem/).
Перевод интервью с Валери Авророй - разработчиком файловых систем для Linux, в данный момент работающей в Red Hat. В разное время она приложила руку к разработке ext2/ext3/ext4 и ZFS и является главным разработчиком chunkFS. Валери комментирует процесс разработки файловых систем и сообщество разработчиков, что лучше использовать в конкретных ситуациях и многое другое.

Там её фотка кстати есть, оказывается не страшная. =) Всегда было интересно посмотреть на женщину разработчика файловых систем.

Jinc
19.07.2009, 13:05
я вот использовал O&O Defrag быстрее стандартного, но какойто подозрительный

Всегда было интересно посмотреть на женщину разработчика файловых систем.
девушки программисты ваше всегда зажигалочки :)

deff
19.07.2009, 13:37
думаю через пару лет ssd накопители наберут обороты, а ещё через пару лет каждый современный комп будет оснащен ими, а на них похрен фрагментирован ли у тебя файл или нет.

DOGOR67
20.07.2009, 08:16
Фрагментацию почему забывают)) это же расположение файлов не жалеют свое HHD оно тоже как человек требует внимания))).

Valgaav
20.07.2009, 08:50
Раз на раз не приходиться.

HeLLFiRE
20.07.2009, 10:08
у SSD при дефрагментации заканчивается срок жизни. так что дефрагментация там противопоказана вообще. и дефрагментация , нужна или нет , зависит от файловой системы, а не от самого харда.

Toor
20.07.2009, 12:58
у SSD при дефрагментации заканчивается срок жизни. так что дефрагментация там противопоказана вообще. и дефрагментация , нужна или нет , зависит от файловой системы, а не от самого харда.

Не все так страшно - моральное устаревание придет раньше, чем выход из строя. Учитывая, что влияние вибрации и тепла на срок службы у SSD-накопителей в разы меньше, чем у НЖМД, то естественный выход из строя в основном ограничивается количеством циклов перезаписи на сектор - сейчас эта величина, как правило, более 100000. Где-то кто-то считал, что этого хватит на 25 лет.

ФС... В свое время про NTFS говорили, мол, фрагментация будет минимальна ;) Правда, нужно отдать должное дядюшке Билли - встроенный API дефрагментации имеет немало функций.

В принципе, есть ФС которые фактически не фрагментируют винт - например, reiserFS. Однако, придется пожертвовать стабильностью и быстродействием (хотя, лично я не замечал потери производительности при включении tail packing'а)...

CHLN
21.07.2009, 23:48
1 раз тока делал дефрагментацию и то на старом харде 6 летней давности 80гб. В те времена он был крутой.

deff
24.07.2009, 12:23
у SSD при дефрагментации заканчивается срок жизни. так что дефрагментация там противопоказана вообще. и дефрагментация , нужна или нет , зависит от файловой системы, а не от самого харда.
SSD не хард,
там нет головки, а значит скорость доступа к фрагментированному файлу такаяже как и к не фрагментированному и износа никакого нету, по этому дефрагментация на них не то что противопоказана, а просто не имеет смысла.

Toor
24.07.2009, 15:17
SSD не хард,
там нет головки, а значит скорость доступа к фрагментированному файлу такаяже как и к не фрагментированному и износа никакого нету, по этому дефрагментация на них не то что противопоказана, а просто не имеет смысла.

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

Jinc
25.07.2009, 14:00
как часто делаете дефрагментацию на нтфс?

DOGOR67
25.07.2009, 16:12
Ну если активно идет перезапись то 1 раз месяц.

Весёлый Молочник
25.07.2009, 18:05
У меня автоматом каждый день в фоне.

wlade
25.07.2009, 21:44
Васче не делаю,,,имхо раньше имело смысл делать,,когда был фат и фат32,,а счас с такими размерами ппц долго делать..Легче перекинуть инфу на переносной хард(нужные доки и т.д.,,искл. торренты--удалять ихнах) и форматнуть диск

House
26.07.2009, 00:12
Васче не делаю,,,имхо раньше имело смысл делать,,когда был фат и фат32,,а счас с такими размерами ппц долго делать..Легче перекинуть инфу на переносной хард(нужны доки и т.д.,,искл. торренты--удалять ихнах) и форматнуть диск

+1

и моё ИМХО :) уже было

Demilich
27.07.2009, 09:19
Дефрагментацию весьма полезно делать. Если есть часто используемые проги или игры большого размера, например клиент ла2 весит 8 гбайт и большая часть из них текстуры и карты, которые всё время подгружаются. Так как все харддиски на внешней стороне имеют пиковую скорость а ближе к внутренней стороне меньшую, желательно перенести их. Проверьте любым тестером дисков, линейную скорость с внешней по внутреннюю.
Если запустить 4 или 8 клиентов ла2 жрущих всю опер. много вирт. памяти +постоянная подкачка с харда, скорость фрагментированного клиента и фрагментированного файла подкачки очень нервирует. Так что без дефрагментации не обойтись, и желательно клиент перенести поближе к краю блина + тоже самое сделать с файлом подкачки вирт. памяти (если 1 хард диск).

Думаю к любому тяжелому приложению или игре это применимо.

DOGOR67
27.07.2009, 11:03
Головке, строго говоря, плевать на дефрагментацию, поскольку "по всей поверхности" она все же не носится (над поверхностью - да). А вот время доступа к файлам может и сократиться.

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

Demilich
27.07.2009, 14:08
Круглосуточная раздача торрентов наверняка намного вреднее чем дефрагментация раз в месяц.

DOGOR67
27.07.2009, 16:06
Круглосуточная раздача торрентов наверняка намного вреднее чем дефрагментация раз в месяц.

+5 С тобой согласен!!! Я имел ввиду кто не дефрагментирует)).

Ammm
28.07.2009, 12:39
виста автоматом делает дефрагментацию каждый день.
я както забыл про это и удивился когда перед собственоручной дефрагментацией запустил анализ.
все было довольно красиво.

medve
30.07.2009, 13:22
а если головка чуток износилась, поможет дефргаментация-форматирование?

Toor
30.07.2009, 13:38
а если головка чуток износилась, поможет дефргаментация-форматирование?

Не-а, любые операции ведут к износу БМГ. В смарт репорте за состояние головок отвечают атрибуты Seek Time Performance, Loaded Hours, Load/Unload Retry Count (особенно актуально), Load Friction, ну и, разумеется, Load/Unload Cycle Count... если хоть один из них близок к threshold, то лучче не рисковать лиший раз.

DOGOR67
31.07.2009, 13:18
а если головка чуток износилась, поможет дефргаментация-форматирование?

Поможет, потомучто срок слжбы двигающихся деталей увеличится. Головка меньше будет носится (двигатся).

rohard
31.07.2009, 16:43
Поможет, потомучто срок слжбы двигающихся деталей увеличится. Головка меньше будет носится (двигатся).

Нельзя судить так однозначно.

Не факт, что винт это переживет - очень часто "чуток изношенные" головы просто падают на блины. Не трудно догадаться, что при множественных циклах записи/чтения вероятность этого неприятного события увеличивается.
Не факт, что головка будет носиться меньше; это даже упамянули выше:
Не случайно в среде администраторов Unix достаточно давно бытует не совсем ортодоксальное мнение о том, что фрагментация файловой системы порядка 25% немного повышает производительность при одновременной работе нескольких приложений, интенсивно и хаотично использующих дисковую подсистему.

DOGOR67
31.07.2009, 17:16
При компактом расположении файлов амплитуда колебаний головки уменьшается - это факт. Да, одназночно судить нельзя, но простые принципы физики тоже думаю действуют. Разбрасонное расположение файлов думаю в сумме при ежедневном использовании думаю приносит больше вреда.

rohard
31.07.2009, 23:15
При компактом расположении файлов амплитуда колебаний головки уменьшается - это факт. Да, одназночно судить нельзя, но простые принципы физики тоже думаю действуют. Разбрасонное расположение файлов думаю в сумме при ежедневном использовании думаю приносит больше вреда.

Если БМГ "хромает", то ни о каком "ежедневном использовании" не может быть и речи - бекап и на покой...

ViPl
01.08.2009, 00:38
Поможет, потомучто срок слжбы двигающихся деталей увеличится. Головка меньше будет носится (двигатся).

А как Вы себе представляете делать дефрагментацию изношеной головкой???

DOGOR67
01.08.2009, 09:38
Ну если ресурс исчерпан, то конечно бекап, если успеет и на покой)). В принципе средний ресурс HDD 2-3 года, но бывают исключения вот хард старого компа работает 5 лет и показатели (с.м.а.р.т.) нормальные - почти как новый. Хотя за эти 5 лет трудился почти ежедневно и подвергался обслуживанию (дефрагментация и.т.д) каждый месяц.

Петя Булкин
01.08.2009, 17:52
Перед дефрагментацией перемещаете большие файлы типа фильмы на другой диск, большие игры - тоже, потом проводите сам процесс, перемещаете обратно... Быстро, дёшево и сердито :) . Ставить какой-нить дефраг фоновый типа ОО - полезно. Раз на раз не приходится, винты сейчас и правда дохнут, как мухи :( . Интенсивная работа с винтом при одной и той-же заполненности приводит к ухудшению участка поверхности - лечится вырезанием этого участка из обращения, на таких участках процесс записи/чтения происходит заметно дольше и зачастую с ошибками.

Opto
01.08.2009, 19:30
Ну если ресурс исчерпан, то конечно бекап, если успеет и на покой)). В принципе средний ресурс HDD 2-3 года, но бывают исключения вот хард старого компа работает 5 лет и показатели (с.м.а.р.т.) нормальные - почти как новый. Хотя за эти 5 лет трудился почти ежедневно и подвергался обслуживанию (дефрагментация и.т.д) каждый месяц.

Какие 2-3 года? Нормативный срок службы больше 5-ти лет.

wlade
02.08.2009, 23:32
хммммм,,,у меня на работе есть диски которым по 10 лет и всё нормально(хоть и исполтзуется активно)

Larionov Aisen
03.08.2009, 00:47
хммммм,,,у меня на работе есть диски которым по 10 лет и всё нормально(хоть и исполтзуется активно)

документы WORD и Excel сохраняют и считывают? =)
Дефрагментация очень полезна! переносиш жирные файлы на другой винт затем сам процесс и обратно жирные файлы на место ИМХО

wlade
03.08.2009, 00:57
документы WORD и Excel сохраняют и считывают? =)
Дефрагментация очень полезна! переносиш жирные файлы на другой винт затем сам процесс и обратно жирные файлы на место ИМХО

raidы в качестве фтпшников в том числе