Назад | Перейти на главную страницу

Насколько точны утверждения Diskeeper о том, что фрагментация вызывает сбои, прерывание загрузки и другие неприятности?

А белая бумага опубликовано Diskeeper Corporation заявляет на странице 3, что,

Наиболее частые проблемы, вызванные фрагментацией файлов:

а) Сбои и зависания / зависания системы
б) Медленная загрузка и компьютеры, которые не загружаются
в) [...]
г) Повреждение файла и потеря данных
д) Ошибки в программах
е) использование ОЗУ и проблемы с кешем

Насколько точны эти утверждения (особенно о сбоях и прерванных загрузках)?

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

Обычное - неправильное слово.

По моему опыту, сильная фрагментация просто тормозит работу. (Медленная загрузка, короткие зависания.) Иногда доходит до тайм-аута приложений, что вызывает нестабильность программного обеспечения, потому что приложение не ожидает этого. Это, в свою очередь, может привести к пунктам a), d) и e), но только как побочный эффект.

Кроме того, на очень сильно фрагментированном диске, который также на 99,999999999% полный файл, повреждение может на самом деле быть проблемой, так как самой файловой системе не хватает места для работы, но в целом вы будете считать, что ПК медленный, чтобы можно было использовать его задолго до того, как вы достигнете этот момент.

Что касается 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 например, все было о команде.)