How accurate are Diskeeper's claims that fragmentation causes crashes, aborted bootups and other mayhem?
В официальном документе, опубликованном Diskeeper Corporation, на странице 3 говорится, что
Наиболее распространенные проблемы, вызванные фрагментацией файла:
а) Сбои и зависания / зависания системы
б) Медленная загрузка и компьютеры, которые не загружаются
в) [...]
г) повреждение файлов и потеря данных
д) ошибки в программах
е) использование ОЗУ и проблемы с кешем
Насколько точны эти утверждения (особенно те, которые касаются сбоев и прерванных загрузок)?
4 ответа
Единственный из тех, кого я лично наблюдал, - это первая часть (b) - более медленная загрузка и вообще более медленный доступ к файлам. Мой личный опыт показывает, что между хорошо дефрагментированным и плохо фрагментированным диском есть ощутимая разница. Насколько это на самом деле влияет на людей, однако я не уверен.
Общее это неправильное слово.
По моему опыту тяжелая фрагментация просто замедляет ход событий. (Медленная загрузка, короткое зависание.) Иногда до момента истечения времени ожидания приложения, что вызывает нестабильность программного обеспечения, поскольку приложение не ожидает, что это произойдет. Это в свою очередь может привести к пунктам a), d) и e), но только как побочный эффект.
Аддитивно на очень сильно фрагментированном диске, который также является полным повреждением файла на 99,9999999999%, на самом деле проблема может быть в том, что самой файловой системе не хватает свободного места, чтобы выполнить свою работу, но в целом вы будете считать, что замедление работы ПК может быть использовано задолго до того, как вы достигнете этот момент.
Что касается f): использование ОЗУ для кеширования, как правило, не увеличится, но эффективность кеширования резко снизится.
В целом: Начиная с Windows XP, файловая система NTFS довольно хороша, если держать фрагментацию ограниченной до разумных уровней сама по себе. YMV, но, по моему опыту, для большинства случаев использования (дома или на серверах) нет реальной необходимости в непрерывной дефрагментации, которую DiskKeeper хочет продать вам.
Для интенсивно используемых (много новых файлов / измененных файлов / удаленных файлов) файловых серверов это другой вопрос: задание дефрагментации с низким приоритетом, работающее в фоновом режиме, действительно может помочь сохранить стабильность времени отклика системы в течение длительного периода времени. То есть, если сервер не используется постоянно с такой интенсивностью в течение 24/7. Программное обеспечение для дефрагментации должно иметь возможность выполнить эту работу. Если он не может выполнять свою работу должным образом, это только ухудшает ситуацию. В таких случаях часто более эффективно записать всю файловую систему на ленту (или другой диск, в наши дни HD-диски дешевы), отформатировать файловую систему и скопировать все обратно. Делайте это каждые X недель, где X зависит от того, когда потеря производительности становится проблематичной.
Я также согласен, что это влияет только на производительность, но, честно говоря, это смягчается тем фактом, что диски и процессоры работают намного быстрее. В старые времена, когда скорость дисковода составляла 66/100/133 МБ / с, это было, вероятно, более заметно, но современные накопители настолько быстры, что, я думаю, вы будете измерять разницу в производительности в миллисекундах... другими словами, не заметно.
Вам лучше всего использовать программу дефрагментации, которая поставляется вместе с вашей ОС, и планировать дефрагментацию раз в месяц, если ваша ОС еще не делает этого автоматически, как Windows 7.
Diskeeper действительно дает подробное обоснование для каждого из этих пунктов в оставшейся части статьи и перечисляет статьи Microsoft, на которых он основывает свой анализ. (Это, конечно, специальный документ для Windows.)
Обращение к прерванным бутстрапам, в частности:
Да, это проблема. Действительно, это тот, который даже не ограничивается Windows NT. Существует несколько загрузчиков операционной системы, которые требуют, чтобы (несколько, но не все) файлы образов программ операционной системы были смежными, поскольку драйвер файловой системы еще не загружен, а код для чтения с диска очень упрощен и может справляться только с смежными файлы (рассматривая их, по сути, как одну многосекторную операцию чтения). Это относится к загрузочным записям тома FAT многих операционных систем и является причиной того, что исторически системные файлы, такие как IBMBIO.COM
(PC-DOS и DR-DOS) и IO.SYS
(MS-DOS) должны были быть смежными.
Конечно, после загрузки кода драйвера файловой системы, который способен полностью понимать структуры данных на диске, что может произойти очень рано во многих операционных системах, фрагментация перестает быть фатальной проблемой и становится просто проблемой производительности ввода-вывода. Так что это только ABEND в случае нескольких операционных файлов начальной загрузки; и, как правило, в любом случае предпринимаются усилия для того, чтобы эти файлы были непрерывными на диске, когда они записываются впервые. (Резервирование смежного пространства, чтобы это было правдой, это то, что /B
вариант для MS/PC-DOS FORMAT
команда была все о, например.)