Источник: Неизвестен

В этом мире живут
как бы по инерции...
К. Моррис

На самом деле вопрос можно поставить даже шире. Была ли вообще данная проблема актуальна где-либо за пределами мира 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 и будет прав). Сегодня подобные программы (отнюдь не только дефрагментаторы) существуют больше как антидот от болезней пользователя, нежели компьютера.

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