Хроника блога. 5

Не прошло и шести лет с того времени, как я начал писать первую книжку про FreeBSD, как настал психологический момент для сочинения второй.
Рабочее название: FreeBSD. Героиня моего романа
Пока сподобился сочинить только оглавление - оно же примерный план будущей книги.
Сразу должен оговорить - это будет не второе изнание книги "FreeBSD: установка, настройка, использование", пусть даже расширенное и дополненное.
Нет, операционки меняются, и мы меняемся вместе с ними. Возможно, даже больше, чем операционки.
И в результате из этого начинания получится совершенно другая книга. Какая - я и сам еще точно не знаю...

FreeBSD: Героиня моего романа

Содержание

• Почему FreeBSD?
  Вместо вступления
• FreeBSD как она есть
  Интрига завязывается
  
• Берклиада
  История одной системы
• Подготовка к выходу
  Что надо иметь, знать и уметь
• Всё имеет свое начало...
  Инсталляция: возможны варианты
• ... И всё начинается с загрузки
  Загрузка и инициализация системы
• На чём стоит FreeBSD
  Диски, разделы, тома, файловые системы
• Файловая иерархия
  Логика файловой системы
• Мир на трёх кашалотах мается
  Файлы, процессы и пользователи
• Темная сторона Луны
  Консоль и терминалы
• Kernelland & Userland
  Ядро и мир FreeBSD
• Вступление в Userland
  Командные оболочки
• Обзор Userland'а
  Системные и пользовательские утилиты
• Ворота в мир FOSS
  Порты и пакеты
• Лики интерфейса
  Xorg, WM и DE
• Главный инструмент Free'шника
  Текстовые редакторы
• Мир без границ
  Интернет и коммуникации
• Конторские будни
  Офисные пакеты и приложения
• В часы досуга
  Графика и мультимедиа
• Что дальше?
  Вместо заключения

Хроника блога. 4

Только-только я подумал, что наконец собрал все свои старые сочинения, как тут, в процессе сочинения нового материала по сравнению быстродействия файловых систем (будет в ближайшее время на Citkit'е), обнаружил несколько заметок о тестировании железа под Linux, файловых систем Linux и FreeBSD, а также серию заметок об оптимизации.

Последняя наиболее занятна. Она написана ещё во времена присноблаженного Линуксшопа, в 2003 году. Вывод из неё - что оптимизация под "железо" и т.д. если и существует, то увидеть её результаты невооружённым глазом весьма затруднительно.

Прошло пять лет. С тех пор, если ситуация и изменилась, то только в худшую (для "оптимизаторов") сторону...

Тестирование Linux'ов. Осень 2003 Тур 4. lame на Athlon'е

2003 г

Результаты lame-тестов на моей машине так заинтриговали меня, что немедленно по размещении итогов предыдущего тура к месту дислокации машины на Athlon-XP/1800+, конфигурация которого была описана в статье о первом туре. И повторил - к сожалению, до того, как ознакомился с соображениями Георгия Шаповалова в нашем форуме, описанными в предыдущей статье. Картина получилась довольно показательная.

Итак, на этой машине имелся Red Hat 9, уцелевший после 1-го тура, содержащий в себе ядро 2.4.20 и gcc 3.2.2. На этом хозяйстве был последовательно собран lame с теми же настройками, что и на моей: уровни оптимизации -O0, -O1, -O2 без всяких дополнительных флагов, сборка lame по умолчанию - напомню, она выполняется с флагами

CFLAGS="-O3 -fomit-frame-pointer \
 -ffast-math -funroll-loops \
 -Wall -pipe"

сборка с флагами

CFLAGS="-O3 -march=i686"

и две сборки конкретно под Athlon-XP. В первой задействовался стандартный сопроцессор:

CFLAGS="-O3 -march=athlon-xp \
 -fomit-frame-pointer \
 -funroll-loops -pipe \
 -mfpmath=387"

Во второй - флаги для мультимедиа-инструкций:

CFLAGS="-O3 -march=athlon-xp \
 -fomit-frame-pointer
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse -m3dnow"

В связи с замечанием Георгия скажу пару слов о том, откуда взялся флаг -funroll-loops. Происхождение его - чисто эмпирическое, в цикле статей о тестировании процессоров на iXBT (недавно узнал, что в народе его, оказывается, ласково называют Хоботом - спасибо @lexb за информацию) было отмечено, что снятие его приводит к провалу производительности (в том числе на AMD64), а поскольку проверять это мне было лень, решил, что джентльменам верят на слово. Впрочем, как показано в конце предыдущей статьи ко 2-й интермедии, рояля это не играет...

Как и ранее, после каждой сборки lame трижды выполнялось конвертирование WAV -> MPEG все того же 750-мегабайтного файла (исключение - для сборки при -O0, причину вы легко поймете, взглянув на таблицу). Как и в первый раз, результаты по lame продемонстрировали просто потрясающую воспроизводимость - в каждой серии отличий более чем на секунду не отмечалось - что в CPU time, что в Real time. Зато здесь я впервые заметил разницу между CPU time и Real time: первое было меньше стабильно на 2-3 секунды. Поскольку результаты по CPU time показали суммарно лучшую воспроизводимость, в таблице и на диаграммах использованы именно они (напомню, что в первом lame-тесте оба показателя были просто идентичны).

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

Таблица. Сравнение средних
-O0	00:13:55
-O1	00:05:07
-O2	00:05:01
Default -O3	00:04:57
-O3 -march=i686	00:04:28
-O3 -march=athlon-xp/387	00:04:28
-O3 -march=athlon-xp/sse	00:04:32

Имеющий глаза все увидит сам, но не откажу себе в удовольствии кратко описать картину:

• резкое повышение быстродействия при применении хоть какой-то оптимизации - разница между -O0 и -O1 - более чем в два с половиной раза;
• едва, но все же заметный, рост производительности от -O1 до -O3 чистого;
• ощутимый прирост скорости при переходе к -O3 -march=i686, составивший почти полминуты;
• абсолютно совпадающий с ним результат для -O3 -march=athlon-xp с задействованием 387;

и, опять же, чуть видимое, но все же - видимое, падение при переходе к сочетанию -march=athlon-xp с наборами sse-типа.

То есть качественно картина практически аналогична полученной для Pentium-4, за исключением отдельных деталей. Так, быстрый сопроцессор Athlon'а помешал, видимо, флагу -funroll-loops отъесть у него производительности. Большие абсолютные значения времени кодирования (все же реально здесь было на один гигагерц меньше, чем на моем агрегате) выявили чуть заметные отличия при уровнях оптимизации -O1, -O2 и -O3. И инструкции sse-типа повредили Athlon'у не так сильно, как "четверке" :-)). Однако все остальное вполне укладывается в наметившуюся ранее тенденцию. Что позволяет сделать уже более определенные выводы.

Помните, как Атос во время завтрака при возвращении в Париж (после истории с подвесками) спросил своих товарищей, что они едят? И когда в ответ те начали расписывать изыски французской кулинарии, возразил: "Господа, вы едите конину. Может быть, даже с седлом".

Так вот, господа, сидящие за крутейшими "четверками" и Athlon'ами и воображащие себя пожирателями трюфелей и омаров (не обижайтесь, это я и про себя). Вы работаете за PentiumPro. Может быть, даже без инструкций mmx/sse... И отсюда - первый вывод: единственные флаги оптимизации, в общем случае окупающие усилия пальцев по их вводу и амортизацию клавиатуры - это

CFLAGS="-O3 -march=i686"

А все остальное, включая mmmx/msse/msse2, способно в лучшем случае не очень ухудшить быстродействие.

Отдельно - о флагах из области mmx/sse. Теоретически они должны бы дать прирост быстродействия. Однако для этого, как резонно заметил Георгий, собираемая с ними программа должна знать о существовании таких инструкций. А похоже, что большинство программ (даже таких, как lame, которой они могли бы принести пользу - чему примером виндовые аналоги) об этом и не подозревают.

И - к слову сказать, правильно делают. Мне всегда казалось, что подмена универсальных инструкций специализированными если и даст сиюминутную выгоду, в долгосрочной перспективе не оправдана: а как завтра Intel выдумает новый набор, mega-sse#? Тогда как старый добрый сопроцессор - он и в Африке сопроцессор...

Второй вывод: пример lame убеждает, что есть программы, не оптимизируемые под процессор (или процессоры, под которые некоторые программы оптимизировать бессмысленно?). Однако мы знаем примеры и противного: ведь те 30 процентов для gcc, полученные таким образом Джастин Piszcz (фамилию транскрибировать не рискну:-))- это реальность (ну пусть не 30, но 10-15% - тоже хороший результат).

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

Тестирование Linux'ов. Осень 2003. Тур 3. Парадоксы оптимизации

2003 г

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

Исследования проводились на моей домашней машине - напомню, это P4/2,53 с 533-мегагерцной шиной, мама на i845PE, памяти - 1 Гбайт (2x512, DDR333), "несущий" винт - Seagate Barracuda IV о 40 Гбайт, прочие компоненты несущественны. Дистрибутив - в девичестве Archlinux 0.5, подвергнутый мною многочисленным операциям по смене пола, наращиванию одними членами и усекновению - других. В итоге чего в нем образовались: ядро 2.4.22 и gcc 3.3.1. Последний был сконфигурирован (вывод команды gcc -v) так:

Configured with: ../gcc-3.3.1/configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib --enable-_cxa_atexit --enable-clocale=gnu
Thread model: posix

А собран командой

$ make bootstrap

со следующими флагами:

CFLAGS="-O3 -march=pentium4 \
 -fomit-frame-pointer
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse2 -fPIC"
CXXFLAGS="$CFLAGS"
BOOTSTRAPCFLAGS="$CFLAGS"

внесенными в профильный файл (/root/.zshrc).

Тратить особо много времени мне не хотелось - некоторым образом и другие дела есть (однако, забегая вперед, замечу, что в итоге я провозился с этими тестами намного дольше, чем рассчитывал). Поэтому я решил выбрать одну, но представительную, задачу. А именно: кодирование WAV -> MPEG программой lame (текущая на тот момент версия 3.92). То есть один из тех классических тестов, на которых всегда демонстрировалось превосходство Pentium 4 над всеми остальными x86-совместимыми архитектурами (на другие тесты, типа преобразования MPEG -> DivX и тому подобное, я потенции в себе не находил).

В качестве объекта для истязания я выбрал wav-файл размером около 750 Мбайт, представляющий собой оцифровку записи концерта Юрия Визбора в альплагере Цей, выполненную с магнитофонной ленты Владимиром Поповым (за что ему - искренняя благодарность). Это я к тому, что никаких проприетарных дисков я не граббил:-)

Итак, для начала я собрал lame в конфигурации по умолчанию. А нужно заметить, что эта самая умолчальная конфигурация предусматривает следующие флаги (их можно подсмотреть в файле ~/lame-xx/configure.in):

-O3 -fomit-frame-pointer -ffast-math -funroll-loops -Wall -pipe

То есть с высоким уровнем оптимизации (хотя, естественно, и без указания конкретного процессора). После этого я перекодировал свой wav-файл просто:

$ lame visbor.wav

Учитывая далеко не студийное качество записи исходного материала, с битрейтами и прочим я решил не возиться. Впрочем, по умолчанию в lame предполагаются достаточно высокие параметры - mpeg layer 1, 44,1 kHz, 128 kbps, qual=2. Результаты трех измерений (по выводу команды lame Real time, которое у меня и здесь, и во всех последующих случаях совпало с выводом CPU time) оказались, как можно видеть из таблицы 1, практически идентичными - 2 минуты 59 секунд в среднем.

Таблица 1

Сборка Gcc 3.3.1
	1	2	3	Avg
Default -O3	00:03:00	00:02:59	00:02:59	00:02:59
-march=p4 with other	00:03:26	00:03:26	00:03:27	00:03:26
-march=i686	00:02:55	00:02:55	00:02:55	00:02:55
-march=p4 only	00:02:56	00:02:56	00:02:57	00:02:56
Сборка Gcc 3.3.2
-march=p4 with other	00:03:29	00:03:26	00:03:26	00:03:27
-O2	00:02:59	00:03:00	00:03:00	00:03:00
-O1	00:03:01	00:03:01	00:03:01	00:03:01
-O0	00:06:19	00:06:19	00:06:19	00:06:19

Пересобираю lame со своими обычными флагами (приведенными выше), которые включают специфичные для "четверки" инструкции и, довольно потирая руки, запускаю конвертацию по новой. Ожидая демонстрации мощи P-4, даже не отправляюсь курить. Тем больше было мое изумление, когда вижу результат - 3 минуты 26 секунд, то есть почти на полминуты худший. Второй и третий прогоны теста картины не меняют (см. табл. 1)...

Н-да, сказал я себе, и пересобрал lame с теми флагами, которые используются при сборке Arch Linux вообще:

CFLAGS="-O3 -march=i686"

Здесь душа моя порадовалась - результаты оказались хоть и чуть-чуть, но получше умолчальных - 2 минуты 55 секунд, причем с идеальной воспроизводимостью (см. табл. 1).

Тут же появляется мысль пересобрать lame, выкинув P4-специфичные флаги и оставив только

CFLAGS="-O3 -march=pentium4"

Результат отличился от предыдущего нечувствительно (однако все-таки в худшую сторону) - 2 минуты 56 секунд :-)...

Однако - подумал я, и решил сменить компилятор на ультрамодерновый gcc 3.3.2, тем более что все равно собирался это делать. Конфигурирую его и собираю точно тем же образом, что и предыдущий:

$ CFLAGS="-O3 -march=pentium4 \
 -fomit-frame-pointer \
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse2 -fPIC"

Configured with: ../gcc-3.3.2/configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib --enable-_cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.3.2

$ make bootstrap

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

Решено - сделано, последовательно пересобираю lame только с флагами

CFLAGS="-O2"

затем

CFLAGS="-O1"

и, наконец,

CFLAGS="-O0"

то есть без всякой оптимизации. Сказалось, но весьма странным образом. Результаты для уровней -O2 и -O1 составили, соответственно, 3 минуты ровно и 3 минуты одна секунда. И только при -O0 я наконец смог удовлетворенно сказать то, что сказали русские мужики после того, как засунули в японскую бензопилу шестигранный лом (из уважения к, возможно, читающим это дамам повторять не буду): результат 6 минут 19 секунд продемонстрировал, что все-таки уровни оптимизации в gcc придуманы были не зря. Что блестяще :-) демонстрирует сводная таблица средних значений (табл. 2) и построенная по ней диаграмма (рисунок).

Таблица 2

Табл. 2. Сравнение средних
-O0	00:06:19
-O1	00:03:01
-O2	00:03:00
-O3	00:02:59
-O3 -march=i686	00:02:55
-O3 -march=p4 only	00:02:56
-O3 -march=p4 etc.	00:03:26

Конечно, все сказанное относится к одной отдельно взятой (и довольно специфической) программе, выполнявшейся на единичном (и также довольно специфическом) процессоре. Тем не менее, некоторые предварительные выводы сделать можно.

А именно - наилучший результат с точки зрения быстродействия достигается при использовании сочетания флагов -O3 и -march=i686 (не случайно CRUX и Archlinux, которые собираются именно так, субъективно казались мне самыми быстрыми дистрибутивами из всего виденного). Впрочем, эффект от этого на практике можно почувствовать только при тотальном о-грабблении пары ящиков сидюков (да и то при условии их конвейерной подачи в привод). Различия же между уровнями оптимизации от -O1 до -O3 можно считать несущественными (рис. 1). Лишь полное отсутствие оптимизации (-O0) ухудшает производительность в значительной мере (более чем в два раза). И - крайности смыкаются - тот же эффект, хотя и не столь выраженный, дает "оптимальная оптимизация" под Pentium 4 (что также имеет органолептическое подтверждение - заоптимизированные до посинения под "четверку" дистрибутивы типа Sorcerer сотоварищи на практике оказываются изрядно задумчивыми).

Рис. 1.

Конечно, интересно было бы посмотреть, имеет ли место такой эффект при экстремальной оптимизации под Athlon. С одной стороны, мои наблюдения более чем двухлетней давности показывают, что еще тогда gcc оптимизировал под него лучше, чем под P4. С другой же - возможно, что в описанном и кроется причина провального результата Gentoo на mkisofs, полученного в первом туре мегатестирования.

И еще один, косвенный (но приятный), вывод: кодирование посредством lame обеспечивает практически идеальную воспроизводимость результатов. И, следовательно, эта программа должна стать непременным членом любого набора пользовательских тестов под Linux.

После сочинения всего сказанного выше я познакомился с мнением Георгия Шаповалова. Он высказал несколько резонных соображений касаемо флагов оптимизации, которые мне, естественно, захотелось проверить (на той же конфигурации).

Для начала, руководствуясь советами Георгия "-march=где-то_рядом и -O2", я пересобрал lame с флагами

CFLAGS="-O2 -march=i686"

получив при этом, однако, чуть-чуть худшие результаты, чем при -O3 -march=i686 (2:57 и 2:55, соответственно).

Потом я вспомнил, что резонные люди советовали не собирать пакеты для Pentium 4 с использованием флага -march=pentium4, а ограничиваться для этого флагом -march=pentium3. Что ж, за нами не заржавеет, собираю lame c

CFLAGS="-O3 -march=pentium3 \
 -fomit-frame-pointer \
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse"

Результат измерений - 2:56. Далее, избавляюсь от вредоносного флага -funroll-loops:

CFLAGS="-O3 -march=pentium3 \
 -fomit-frame-pointer \
 -pipe -mfpmath=sse -mmmx -msse"

Результат неизменно превосходен - 2 минуты 56 секунд :-)

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

Таблица 3

Таблица. Результаты lame-теста для P4
-O0	00:06:19
-O1	00:03:01
-O2	00:03:00
-O3	00:02:59
-O2 -march=i686	00:02:57
-O3 -march=i686	00:02:55
-O3 -march=p4 only	00:02:56
-O3 -march=p4 sse funrall	00:03:26
-O3 -march=p3 sse funrall	00:02:56
-O3 -march=p3 sse w/o funrall	00:02:56

Рисунок 2

Увы - картина все та же (рис. 2): резкое падение быстродействия при -O0, ощутимое - при -march=pentium4 со всеми sse-прибамбасами, прочие же случаи - практически равны...

Тестирование Linux'ов. Осень 2003. Тур 2. Про prelink

2003 г

Разговоры про prelink и его фантастическую способность к ускорению запуска Linux-приложений ведутся давно. Достаточно вспомнить ставший знаменитым тест Хосе Суареса. В итоге и у меня появилось желание посмотреть, что же это такое. А в рамках начавшегося мегатестирования - и померять, как этот самый prelink влияет на реальную работу.

Издевательству подвергался дистрибутив Archlinux (последняя стабильная версия, 0.5), который сам по себе заслуживает внимания (и оное надеюсь уделить ему в ближайшие дни). Насколько мне известно, собирается дистрибутив с флагами -O2 -march=i686, то есть без особых изысков. Тем не менее, субъективно он производит впечатление весьма быстрого.

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

Для начала скачиваю prelink с места его постоянного проживания - ftp://people.redhat.com/jakub/prelink, - и распаковываю архив. Затем внимательно читаю ./configure --help и запускаю собственно конфигурирование:

$ ./configure --prefix=/usr

в ответ на что от меня требуют библиотеку libelf. Она также имеется среди пакетов Arch, однако чистоты эксперимента для собираю и ее. Скачиваю его последнюю (0.8.2) версию с http://www.stud.uni-hannover.de/~michael/software/, разворачиваю тарбалл и собираю обычным образом -

$ ./configure --prefix=/usr ;
$ make ;
$ make install

После чего повторяю процедуру конфигурирования prelink, по благополучном ее завершении запускаю make - и получаю сообщение об ошибке. Причем, что самое обидное и парадоксальное - на стадии сборки компонентов для архитектуры PPC, нужной мне, как зайцу стоп-сигнал. Я довольно долго ломал голову, как побороть эту напасть - снятием ли флагов оптимизации, или искоренением из make-файлов упоминаний о не-PC'шных архитектурах. И в конце концов в глубине кроны дерева портежей Gentoo обнаружил специально предназначенный к тому патч. Он залегает в отростке portage/sys-devel/prelink/files и носит имя prelink-20030505-glibc231.patch (к сожалению, более простого способа его получения в не-Gentoo-дистрибутивах я не обнаружил - разве что самому написать:-)). Несовпадение номеров версий патча и собственно prelink смущать тут не должно - все описанное проверено на собственной шкуре и работает.

Итак, налагаю патч:

$ patch -Np1 -i /path/prelink-20030505-glibc231.patch

после чего сборка prelink проходит безболезненно.

В результате я получаю исполняемый файл /usr/sbin/prelink и соответствующую ему man-страницу. По изучении которой нужно выполнить некоторые конфигурационные мероприятия. А именно - скопировать из каталога doc в дереве исходников prelink файл prelink.conf:

$ cp ~/prelink-src/doc/prelink.conf /etc

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

-l /bin
-l /usr/bin
-l /sbin
-l /usr/sbin
-l /usr/local/bin
-l /usr/X11R6/bin
-l /opt/qt/bin
-l /opt/kde/bin
-l /usr/libexec
-l /lib
-l /usr/lib
-l /usr/local/lib
-l /usr/X11R6/lib
-l /usr/X11R6/LessTif
-l /opt/qt/lib
-l /opt/kde/lib

Теперь можно, наконец, запустить процесс предварительного связывания. Делается это так:

$ prelink -avfmR

Смысл опций команды следующий: -a предписывает применить прелинкинг ко всем исполняемым файлам; -v - выводит подробную информацию о ходе процесса; -f - директива применять прелинкинг повторно, даже если эта процедура уже была выполнена; -m и -R - опции, страхующие от ошибок нехватки памяти и переполнения буфера (подробности, как обычно, - на man prelink).

Особо подчеркну необходимость опции -v. Я бы даже советовал отправить вывод команды (вернее, ее сообщений об ошибках) в файл:

$ prelink -avfmR 2> prelink.log

Без этого трудно узнать, какие программы подверглись прелинкингу, а какие - нет. Ибо те, что были собраны с опцией non-PIC (или, напротив, без опции --with=pic), предварительно связанными быть не могут. У меня в этот черный список попало некоторое количество KDE-приложений, что, возможно, и отразилось на результатах тестирования, приводимых ниже.

Выход из этого положения - простой, но занудный: пересобрать все, что попало в prelink.log. И тут уж, разумеется, впредь не забывать, что любая программа, в выводе ./configure --help которой отмечается доступность опции --with-pic, должна конфигурироваться именно с ее участием. Для гарантии чего флаг -fPIC можно добавить в список значений переменной CFLAGS. А после этого - повторить процедуру прелинкинга, для чего, собственно, и требуется упоминаемая выше опция -f - без нее программы повторно прелинкованы не будут.

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

• Pentium4/2,53 (шина 533 Mhz, без Hyper Treading'а);
• "Мама" Albatron PX845PE ProII;
• память - 2x512MB, DDR PC333;
• видео - от того же Albatron'а, GeForce 4 440MX;
• HDD - Seagate Barracuda IV, 3 шт. - 40 Гбайт на 1 мастере, 80 Гбайт на 1 слейве, 80 Гбайт на 1 мастере;
• CD-R/RW Teac - скоростей не помню, смотреть лень, да и рояля не играет;
• всякое прочее типа клавы, мыши и прочего, к делу не относящегося.

Раскладка дисковых разделов:

• корневой (500 Мбайт) - на 1-м мастере;
• /boot (50 Мбайт) на нем же;
• /var и /usr (1 и 10 Гбайт, соответственно) там же, оба logical (все прочие - primary);
• два swap-раздела по 1 Гбайт - на 1-м слейве и втором мастере;
• /home - 160 Гбайт без двух на soft-RAID из 1-го слейва и 2-го мастера.

Система, как уже было сказано, - Archlinux 0.5, с ядром, поднятым до 2.4.22, gcc 3.0, glibc 2.3.2, binutils 2.14 с www.gnu.org, XFree86 4.3.0, KDE 3.1.4, установленные из пакетов. Графический режим - 1280x1024, 16 bit, стандартный X-сервер, без драйверов nvidia. Больше, пожалуй, добавить нечего.

Измерялась скорость запуска самого KDE и следующих KDE-приложений: konqueror'а как браузера и его же как файлового менеджера (с моими профилями), текстового редактора kate, почтовика kmail и KWord из комплекта KOffice.

Методика: сначала, после перезагрузки системы, запускалось KDE с измерением времени. Затем в сеансе KDE замерялось время запуска перечисленных приложений в указанном порядке. После этого - выход из сеанса и перезагрузка, после чего процедура повторялась второй раз. Результаты приведены в таблице.

Таблица

Тест	W/o prelink			With prelink			With/Without
Программа	1st	2nd	Avg	1st	2nd	Avg	Avg
KDE	17,94	18,16	18,05	19,13	19,19	19,16	1,06
Konqueror-Web	2,16	1,78	1,97	1,25	1,57	1,41	0,72
Konqueror-FM	2,12	1,78	1,95	1,87	1,84	1,86	0,95
Kate	1,91	1,85	1,88	1,69	1,62	1,66	0,88
Kmail	2,03	2,06	2,05	1,69	1,91	1,80	0,88
KWord	1,91	1,72	1,82	1,47	1,38	1,42	0,79

Можно видеть, что хотя прелинкованное KDE запускается чуть медленнее, чем до prelink, каждое отдельно взятое KDE-приложение стартует несколько (на 5-28%) быстрее - вывод о том, стоит ли игра свеч, предлагается сделать самостоятельно. Однако можно точно констатировать, что представленные измерения далеко не дотягивают до результатов Хосе - возможно, именно вследствие того, что не все компоненты Qt и KDE подверглись прелинкингу.

Тестирование Linux'ов. Осень 2003. Тур 1. Gentoo против Red Hat

2003 г

Учера, у США... нет, не бойтесь, не увбили там Мартына ЛУтера КингА. И даже товарища Кирова там не увбили. И вообще, убивали там не кого, а только чего - конкретно, собственное время. И убивали его в целях сугубо благородных - то есть, можно сказать, приносили в жертву, - в жертву ответу на извечный вопрос: кто на свете всех быстрее, всех стабильней и милее.

То есть: глобальное супермегатестирование дистрибутивов Linux (а в дальнейшем и прочих Open-*nix'ов), о необходимости которого так долго говорили большевики и меньшевики, анархисты и анархо-синдикалисты, государственники и почвенники, славянофилы и нигилисты, - короче говоря, линуксоиды всех стран, национальностей и концессий, - наконец-то, свершилось. Вернее, не столько свершилось, сколько - нАчалось. В любом случае, можно констатировать: процесс пошёл... Будем надеяться, что дальше можно ожидать ситуации, когда "процесс сам по себе идёт". Но об этом - под занавес нашего репортажа.

Генеральной идеей первого тура было: сравнить "умолчальное" быстродействие коренных представителей двух струй современного майнстрейма в Линукс-дистрибутивостроении: Red Hat как представителя пакетной линии, и Gentoo - от сборной Source Based. В дальнейшем предполагалось привлечь к ответу ещё одну пару - Mandrake от монстроизируемых максималистов и CRUX (или его клон Archlinux) - от течения здоровых минималистов.

Решено было нАчать с Gentoo - поскольку процесс его установки обещал быть более длительным. Здесь уместно сказать, на чем тестирование осуществлялось. По это дело была выделена такая машина:

• материнская плата MSI 6561 на чипсете SiS 745 под сокет A;
• в сокете находился Athlon XP 1800+ (этот индекс в пересчёте на простые мегагерцы примерно соответствует 1500 Mhz);
• 768 Мбайт памяти - два модуля в 512 и 256 Мбайт, соответственно (вытаскивать оные, для уточнения родословной, по правде говоря, было лень);
• видеокарта на GeForce2 MX о 32 Мбайт памяти, генетика её точно установлена не была;
• винчестер IBM/Hitachi на 80 Мбайт, 7200 обормотов в минуту в виде мастера на первом IDE-канале;
• сетевая карта от Intel (точное название не записал - да и вряд ли это принципиально);
• прочие компоненты (типа CD - слейва на втором канале, мыши, клавы, встроенного звука, к теме нынешнего занятия прямого отношения не имеющие.

Диск был разбит в соответствие с рекомендациями разработчиков - эмулируя процесс установки малоопытным юзером, держащимся документации, яко воинского устава (хотя, положа руку на сердце, кто рискнёт сказать, будто-бы, будучи малоопытным юзером, в документацию вообще заглядывал?). Так что на винте были учреждены: корневой раздел (/ - /dev/hda3) на 80 Гбайт, загрузочный (/boot - /dev/hda1) - на 84 Мбайт, и раздел подкачки (swap - /dev/hda2). Файловые системы - ext3fs как для /, так и для /boot (не говорите мне, что в последнем случае это бессмысленно - так уж исторически склалось).

Уже на первой стадии тестирования подстерегали тяготы и лишения. Так. упорно не желала настраиваться сеть. Были шероховатости и при настройке Иксов - впрочем, в конце концов, преодолённые. Однако времени на это ушло больше, чем планировалось в соответствие с генеральной линией партии...

Тем не менее, и из этих непредвиденных осложнений можно было сделать первый вывод о тестировании. А именно - из пакетов нужно ставить пакетные же дистрибутивы, тогда как Source Based самим Господом заповедовано собирать из исходников...

В программу тестирования вошли:

• традиционный тест линуксоидов сборка ядра (конкретно - канонической vanilla с kernel.org, версии 2.4.21, штатно входящей как в Gentoo, так и в Red Hat (тогдашних версий - напомню, дело происходило в октябре 2003 г.); конфигурация ядра - по умолчанию, после ответа на несколько вопросов, оказавшихся обязательными;
• архивирование и компрессия содержимого первого официального инсталляционного диска Gentoo 1.4, предварительно, разумеется, скопированного на винчестер;
• создание iso-образа из того же материалу, то есть из каталога с файлами первого установочного Gentoo-диска.

Дабы не полагаться на секундомер и прочую органолептику, время начала и конца операции во всех случаях фиксировалось командами date. То есть тест на сборку ядра проводился следующим образом:

$ date > kernel# ; \
make dep && \
make clean bzImage modules modules_install && \
date >> kernel#

Архивирование и компрессия:

$ date > tar# ; \
tar cjpvf cd1.tar.bz2 cd && \
date >> tar#

Создание образа:

date > iso# ; \
mkisofs -R -J -o cd#.iso cd && \
date >> iso#

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

Далее (на те же самые разделы, с пересозданием тех же файловых систем) был установлен Red Hat 9 (с 3-дискового set'а, по возможности в минимальной комплектации), после чего отданы те же команды, что и ранее для Gentoo. А вот результаты - результаты оказались столь неожиданными, что я не буду о них распространяться, а просто приведу таблицу и график.

	Gentoo				Red Hat
Тест, час:мuн:cek	Дубль 1	Дyбль 2	Дyбль 3	Среднее	Дубль 1	Дyбль 2	Дyбль 3	Среднее
Ядро	00:07:30	00:07:29	00:07:32	00:07:30	00:06:25	00:06:20	00:06:27	00:06:24
Tar.bz2	00:12:41	00:12:18	00:12:18	00:12:26	00:11:16	00:11:18	00:11:16	00:11:17
Mkiso	00:03:00	00:02:59	00:03:00	00:03:00	00:00:18	00:00:18	00:00:18	00:00:18

Пара слов о методике. Таблица была составлена в OpenOffice.org 1.1.0. Значения в ней получены как разность вывода команды date после и до исполнения соответствующей команды, среднее также подсчитано автоматически (при формате ячеек, заданных как time). Так что наблюдаемые эффекты нельзя списать на мои ошибки в арифметике. График также построен в OpenOffice и экспортирован в GIF.

В принципе, цифры и диаграмма говорят сам за себя. Для тех же, кто не верит своим глазам, дам краткий комментарий. Red Hat, не смотря на свое пакетное происхождение и отсутствие какой-либо оптимизации под наличный процессор (напомню - Athlon XP) демонстрирует небольшое, но уверенное преимущество перед пакетным же Gentoo в тестах на сборку ядра и архивирование/компрессию. Которое становится просто подавляющим в тесте на создание iso-образа...

Объяснений этому факту у меня нет. Единственное, что приходит в голову - кривизна конкретной версии (или конкретной сборки) mkisofs в Gentoo.

Fujitsu HandyDrive в Linux: парадоксы быстродействия

2004 г

Сразу должен предупредить - данная заметка содержит весьма тривиальное заключение о работе в Linux устройства, имя которого вынесено в подзаголовок. А именно: устройство это в Linux работает:-). Так что те, кому требуется лишь конечный вывод, дальше могут не читать. И еще: заметка была написана давно - летом 2004 года. И где-то заваляляась - или я ее куда-то посылал, и ответа не получил. А нынче вспомнил в связи с измерением быстродействия флешек - и решил разместить.

Возможно, по сему поводу не стоило бы и огород городить. Если бы не некоторое время назад не попалось мне на глаза сообщение о том, что приводы ZiV-типа (также с USB-интерфейсом) сертифицированы на совместимость с ASPLinux. Хотя, казалось бы, чего сертифицировать - USB-привод он и в ASPLinux'е USB-привод... И я подумал - а нет ли тут каких-нибудь подводных камней? А когда их не обнаружилось, дабы не было мучительно больно за..., ну, наверное, за несложившийся сюжет, подверг титульный дивайс всяким измерительным издевательствам. Которые принесли результат совершенно неожиданный...

Однако начну по порядку.

Зачем нужны мобильные накопители

За последние годы ноутбуки катастрофически приблизились к настольным машинам по своим возможностям. Они обзавелись 15- и более дюймовыми матрицами, процессорами, годными для почти любых реальных задач, объем памяти в них достиг практически разумного максимума, приводами DVD-CD/RW и даже DVD/RW. А изобилие портов USB 2 и Firewire позволяет подключать практически любую, в том числе и высокоскоростную, периферию.

Лишь в одном отношении ноутбуки продолжают радикально проигрывать десктопам (не считая цены, конечно) - в объеме винчестеров. Действительно, стандартные 40 и даже 80 ноутбучных гигабайт выглядят весьма бледно по сравнению со своеобычными для их настольных собратьев винтами в 120-160 Гбайт. Главное же - наращивание дискового пространства, столь легкое в десктопах, в ноутбуках выглядит несколько проблематично как с финансовой точки зрения (ноутбучные винчестеры при прочих равных вдвое дороже настольных), так и технически. Далеко не в каждый ноутбук можно вкрутить второй винчестер (и, как правило, вместо чего-то другого). Замена же имеющегося а) не всегда решает проблему дискового пространства (при нынешних объемах данных что 40 Гбайт, что 80 - разницы часто нет) и б) связано с весьма сложной процедурой переноса системы и данных.

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

Так что когда я волею судеб сменил свой громоздкий декстоп, забитый винчестерами (суммарным объемом более 200 Гбайт) по самые уши, на компактный ноутбук со скромным винтиком в 40 Гбайт, первой насущной проблемой стало расширение дискового пространства.

Какие они бывают

Принцип устройства мобильных винчестеров настолько прост, что остается только удивляться - почему до него никто не додумался ранее. Действительно, это - всего-навсего коробка (пластмассовая или металлическая), в которую вставляется самый обычный настольный винчестер - обычно ноутбучный, 2,5", хотя имеются и трехдюймовые решения.

Поскольку внутренность такой коробки снабжена обычным IDE-разъемом, не предусматривающим возможности внешнего подключения, она должна быть снабжена интерфейсом, таковое допускающим - ATA -> USB или ATA -> Firewire. Не худо также озаботиться электропитанием винчестера, хотя в случае подключения к USB-шине последняя способна справиться со снабжением энергией самостоятельно.

Мобильные накопители предлагаются в продаже в двух вариантах - как голые коробки, которые пользователь должен комплектовать винчестером самостоятельно, как готовые решения, с уже подобранным накопителем. Чем обуславливается более высокая суммарно цена последних. Хотя, как будет показано в дальнейшем, это не лишено оснований.

Для меня в силу ряда причин (в частности, отсутствия требования собственно мобильности) наибольший интерес представляли решения на базе настольних трехдюймовых винчестеров. Однако в пределах досягаемости таковых не обнаружилось (и, честно говоря, я уже не помнил, где мне попадались их описания). Так что пришлось заняться изучением двухдюймовых конструкций - благо, только что они были очень подробно описаны в специальном обзоре.

Правда, сведения из этого обзора (очень информативного) практически помогли мне мало: в тех же пределах досягаемости предложение исчерпывалось ZiV-приводами, которые я не рассматривал ввиду явно неоправданной цены, и приводами Fujitsu Handy Drive. Один из представителей которых и был приобретен.

Упомянутый обзор избавляет меня от необходимости подробного описания дивайса. Скажу только, что мне в руки попала модель с интерфейсом USB 2 (т.н. Data Edition) объемом 40 Гбайт.

Подключение

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

Итак, присоединяю один конец штатного кабеля к накопителю, другой - к USB-разъему выключенного ноутбука (обходясь без сетевого питания, ибо соответствующий шнур в комплекте не прилагается) и запускаю машину. На корпусе драйва загорается индикатор питания. Однако по окончании загрузки операционки никакого намека на новое устройство в каталоге /dev не обнаруживается. В душу закрадываются всякие нехорошие мысли (например, что питала через USB-разъем приводу не хватает). Однако духом не падаю - выдираю кабель из разъема и втыкаю уже "на горячее". Ура - команда

 ls /dev 

показывает сразу два новых устройства - /dev/sda, соответствующее накопителю в целом, и /dev/sda1, отвечающее дисковому разделу на нем. Что позволяет сделать сразу два вывода:

• подобно флэш-накопителям с USB-интерфейсом, HandyDrive предстает перед системой в качестве обычного SCSI-винчестера;
• фабрично он размечен как единый первичный раздел (что отнюдь не представлялось мне очевидным - те же флэш-драйвы фабрично размечаются самым причудливым образом, а иногда просто предстают перед системой как неразмеченное raw-устройство).

Попытка монтирования устройства командой

 mount /dev/sda1 /mount_point 

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

 mount -t vfat /dev/sda1 /mount_point 

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

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

Теперь остается только обеспечить возможность монтирования привода в полуавтоматическом режиме, в том числе - и от лица обычного пользователя. Для чего в файл /etc/fstab вносится следующая запись:

 dev/sda1 /mnt/hd reiserfs \ user,noauto,notail,noatime,nodiratime,exec 0 0 

Значение первых трех полей очевидно (имя файла устройства, точка монтирования, файловая система). Смысл же опций монтирования следующий:

• user позволяет монтировать устройство обычному пользователю, без прав root-оператора;
• noauto означает отказ от автоматического монтирования при старте системы (тем паче, что устройство становится видным только при горячем подключении - впрочем, возможно, что это особенность конкретной реализации udev);
• exec разрешает запуск с устройства исполняемых файлов, по умолчанию невозможный 9даже при наличии бита исполнения);
• notail - специфичная для ReiserFS опция, вызывающая отказ от т.н. "упаковки хвостов" (что несколько экономит дисковое пространство, но приводит к ощутимому снижению производительности);
• noatime и nodiratime - очень полезные опции, отменяющие обновление времени последнего обращения (атрибут atime) к файлу и каталогу, соответственно; специальное исследование показало, что таким простым средством именно для ReiserFS скорость некоторых файловых операций можно увеличить на 10-50%.

Отныне HandyDrive можно в любой момент смонтировать простой командой

 mount /mnt/hd 

Важное замечание относится к совместному использованию HandyDrive с USB-флэшками: чтобы не утратить возможность монтировать его указанной командой, нужно следить за тем, чтобы он подключался к машине раньше последних, иначе имя файла устройства его будет отличным от определенного в файле /etc/fstab (например, /dev/sdb1). Сказанное относится не только к случаю задействования механизма udev, но и к использованию файловой системы devfs (где возможны еще и некоторые другие дополнительные осложнения - например, при неоднократном подключении/отключении HandyDrive в течении сеанса работы).

Как видите, использование HandyDrive в Linux очень просто, и ни в какой сертификации не нуждается (если угодно, мою ,заметку можно рассматривать в качестве таковой:-)). У меня есть глубокие подозрения, что и со всеми остальными мобильными приводами из числа USB-устройств дело обстоит не сложнее:-).

Методика измерения

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

В свое время для целей сравнения быстродействия файловых систем я подобрал набор простеньких тестов - копирование массива смешанных данных общим объемом около 800 Мбайт, копирование большого (700 Мбайт avi-файла), развертывание, копирование и уничтожение архива дерева портов FreeBSD (подробно методика описана здесь). И ничто не мешало применить эти тесты, с некоторыми коррективами, для измерения физического быстродействия дисковых устройств. Чем я и занялся.

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

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

Да, чуть не забыл сказать: перед началом измерений в BIOS ноутбука были выключены все опции, имеющие отношение к энергосбережению. Правда, избавиться от "засыпания" винчестера совсем BIOS Setup данной машины не позволяет, однако я выставил его на максимум - 30 минут; а поскольку все тесты занимают существенно меньшее время, это не должно сказаться на из результатах. Ну и сами измерения производились при питании ноутбука от сети.

Таблица. Результаты копирования, с, среднее из 3
Тест	Data	Big file
Barracuda	89	47
Int HDD	146	106
Fujitsu HD	140	70
Int2HDD	91	60
HDD2Int	68	58

Примечание: Int2HDD - в разделе внутреннего винчестера ноутбука; Fujitsu HD - в разделе на винчестере HandyDrive; Int2HDD - с раздела ноутбучного винчестера на HandyDrive; HDD2Int - с HandyDrive на винчестер ноутбука.

Для начала в качестве точки отсчета я решил выполнить оба теста на винчестере моего ноутбука - как можно заключить по косвенным данным (в документации сведения на сей счет отсутствовали), производства Toshiba (как ни странно:-)), объемом 40 Гбайт и скоростью вращения 4200 об./мин. Быстродействие его утилитой hdparm определялось так:

/sbin/hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads:   \
74 MB in  3.06 seconds =  24.15 MB/sec

Для сравнения, мои предыдущие настольные винчестеры (Seagate Barracuda IV, 40 и 80 Гбайт, 7200 об./мин.) показывали таким образом более 40 MB/sec, относительно низкоскоростной (5400 об./мин.) 30-гигабайтник Fujitsu (из тех самых приснопамятных, случайно уцелевший:-)) - около 30 MB/sec. То есть винт, прямо скажем, в моей Toshiba стоит не рекордный. Что и подтвердилось измерениями, результаты которых приведены в таблице и на диаграмме.

Копирование осуществлялось внутри каталога /home, расположенного на отдельном первичном разделе объемом около 30 Гбайт и несущем ту же файловую систему ReiserFS, монтируемую автоматически с теми же опциями, что и сменный носитель HandyDrive:

/dev/hda4 /home reiserfs notail,noatime,nodiratime 0 0

В качестве объекта сравнения я использовал также ранее полученные результаты для Seagate Barracuda IV, 80 Гбайт (скорость вращения 7200 об./мин.), при использовании той же файловой системы ReiserFS, смонтированной с аналогичными опциями. Напрямую сравнивать их в нынешними не следует (они были получены на машине с другим процессором (Pentium-4/2,53 против Pentium-4M/2,66 в ноутбуке), при другом ядре (2.6.6) и при других версиях прочего софта, однако качественное представление в разнице быстродействия десктопного (весьма среднего по современным мерка) и ноутбучного винчестеров получить можно.

Парадоксы быстродействия

В итоге время копирования массива данных на внутреннем винчестере заняло 144-149 с, большого файла - 100-118 с. То есть в полтора-два раза больше, чем на своеобычном десктопном диске. Что было вполне ожидаемо, хотя обращает внимание приличный разброс результатов - для настольних винчестеров воспроизводимость была, как правило, существенно лучшей.

Рисунок. Диаграмма результатов тестов, по данным таблицы.

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

И тут показалась первая ласточка грядущих неожиданностей: время копирования массива данных действительно оказалось близким (138-141 с), причем результаты HandyDrive если и отклонялись, то в лучшую сторону. А вот на большом файле внешний накопитель вырвался вперед почти на треть, при лучшей воспроизводимости результатов (68-72 с).

А дальше начались совсем странные вещи. Собственно, предметом моего исследования была скорость обмена данными между внутренним и внешним накопителями в том и в другом направлении. Так вот, копирование с ноутбучного винчестера на HandyDrive заняло 90-92 с для массива данных и 59-60 с - для большого файла, что уже сопоставимо с "внутренней" скоростью десктопного диска (причем стоит обратить внимание, что воспроизводимость результатов ее улучшилась по сравнению с обоими "внутренними" тестами). А соответствующие значения в обратном направлении (с HandyDrive на ноутбук) составили 66-69 и 56-59 с - то есть для массива данных даже лучше, чем для настольной "Барракуды" с почти вдвое большей скоростью вращения...

Заключение

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

Более вероятно, что объяснение отмеченному феномену следует искать в особенностях файловых систем Unix-подобных операционок с их эффективным кэшированием дисковых операций. Что особенно ярко проявляется в отчаянно-асинхронной ReiserFS. Правда, остается не вполне понятным, почему эта асинхронность сильнее проявляется при передаче данных через интерфейс USB, нежели через внутренний ATA-контроллер...

Как бы то ни было, практический вывод для конечного пользователя однозначен: внешний накопитель HandyDrive с позиций быстродействия не уступает, мягко говоря, внутреннему ноутбучному винчестеру. И потому может использоваться не только для целей резервирования/транспортировки данных, но и как повседневный рабочий носитель информации.

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

Разумеется, при выполнении трех условий: наличия интерфейса USB 2, использования ОС Linux и файловой системы ReiserFS. Первая оговорка в комментариях не нуждается (о перекачивании гигабайтов данных через USB 1.1 страшно даже подумать). Что же касается последней - нельзя гарантировать столь же быстрой работы HabdyDrive с иными файловыми системами, поддерживаемыми Linux (исходя из общих соображений, можно предположить, что в случае с XFS более эффективным окажется интерфейс FireWire). Что же касается ОС - от FreeBSD с ее полусинхронной UFS/UFS2 высокой производительности ожидать трудно. Ну а про Windows и говорить не хочется - тем более, что выводы в этом отношении можно сделать из цитировавшегося обзора.

Две флеши, или все ли йогурты одинаково полезны?

2004 г

Давеча попали мне в руки две флешки емкостью 256 Мбайт каждая, и с интерфейсом USB2.0. А поскольку они могли пролежать у меня некоторый период, да и у меня выпала толика времени, решил я попробовать ответить на вопрос, вынесенный в подзаголовок этой заметки

Имена производителей обеих флешек не блистали славой (по крайней мере, мне были неизвестны; хотя во втором имени почудилось что-то знакомо-брендовое, но, как станет ясно в дальнейшем, только почудилось): первую звали SeitecUSB2.0, вторая отзывалась на погоняло TwinMOS Mobile Disk. Стоили они одинаково, что заставляло предполагать их беспородно-китайское происхождение (собственно, в этом качестве они и были мне проданы в дружественной фирме). Однако некоторые различия устанавливались между ними уже органолептически.

Флешка имени Seitec выглядела как элегантная серебристая минисубмарина. И комплектовалась она, кроме шнурка для привязывания за шею (истинному компьютерщику такой дивайс заменяет нательный крест), мини-CD с драйверами для Windows низшего пошиба, а главное - шнурком-удлинителем для подключения к разъему USB; штука очень не лишняя, если корпус машины не имеет таковых на лицевой панели (или в иных удобных местах). Устройство же памяти товарища TwinMOS'а, при строгом, казалось бы, черно-белом окрасе, выглядело как-то не аккуратно. И не имело в комплекте ничего, кроме коротенькой веревочки, призванной символизировать брелок для часов (даже с колечком). И драйвера, и удлинитель, видимо, сочли излишеством.

Однако в данный момент это меня не волновало, так как предполагалось их подключение к ноутбуку с удобно расположенными USB-портами, на котором в качестве ОС была установлена DragonFlyBSD, в такой мелочи, как драйвера, не нуждающаяся.

Так что я последовательно подключил оба устройства и полюбовался на них посредством команды

$ fdisk /dev/da0

Думаю, не нужно напоминать (на Руси об этом уже каждый ребенок знает), что в Unix-подобных системах любые накопители с USB-интерфейсом предстают в качестве винчестеров SCSI (отсюда аббревиатура da - Direct Access). Не стали исключением и мои "зажигалки".

Указанная выше команда показала, что оба "диска" были размечены как 1-я primary partition (1-й слайс, в BSD-терминологии). Что отнюдь не очевидно - до сих пор мне почти не встречалось одинаково размеченных флешек. И отформатированы под файловую систему VFAT, с доступом к которой в любой BSD-системе (да и Linux'е) проблем не возникает. Однако тут выявилось еще одно различие: флешка Saitec показала форматированную емкость 249 Мбайт, а TwinMOS - только 247 Мбайт. Пустяк, конечно, - но ведь не так давно мы писали свои данные на дискеты меньшего объема. Да и причина разницы осталась неясной - разметка одинакова, никаких скрытых разделов со служебными файлами, призванными обеспечить секретность (на флешках и такое встречается) не обнаруживалось ни на той, ни на другой.

Однако заморачиваться этим я не стал, потому как задумался о способе измерения быстродействия обеих дивайсин. Ничего лучшего, чем копирования, мне в голову не пришло. В качестве первого объекта копирования я выбрал текущий срез своего сайта (unix.ginras.ru - набор большого количества файлов разного, преимущественно небольшого, размера, суммарно составляющие на текущий момент 75 Мбайт (во разросся-то сайт - и меньше чем за год). Вторым же стал avi-файл в 80 примерно мегабайт. Был сочинен соответствующий скрипт, предполагающий временные отметки для обеих операций - и вперед. Каждая пара измерений на каждом устройстве проводилась трижды, в промежутках устройство, разумеется, размонтировалось. Средние арифметические для трех пар замеров (в секундах) приведены в таблице.

Таблица. Результаты копирования

Модель	Many files	Big File
Seitec	206	170
TwinMOS	342	264

Не правда ли, неожиданно? При одинаковых параметрах (формальная скорость трансфера, по данным того же fdisk, у них также одинакова), модель от Seitec показала превосходство в скорости более чем в полтора раза, особенно явное при копировании массива разнородных файлов (см. рисунок).

Рисунок. Диаграмма результатов копирования

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

UFS: эффект асинхронного монтирования

2004 г

Обескураживающие результаты тестирования файловой системы FreeBSD (UFS2, принятая в качестве нативной в 5-й ветке), выполненные ранее, не давали мне покоя. И даже то, что при использовании программного RAID (измерения проводились на дисках, объединенных ccd) скорость файловых операций уже не смотрелась столь мрачно, дела не меняло -- ведь сама по себе файловая системы тут не при чем.

И потому, установив новую ОС - DragonFlyBSD, - я решил вернуться к тестам на скорость файловых операций. В отличие от FreeBSD 5-й ветки, DFBSD сохранила верность первой версии файловой системы UFS. На этот раз в центре внимания был эффект асинхронного монтирования при отключении SoftUpdates - результаты предыдущих измерений показали, что при включении последнего механизма опция async просто игнорируется. Хотя, должен заметить, так было не всегда: в известной статье МакКазика и Ганджера (русский перевод) описаны результаты измерения быстроты файловых операций при включении SoftUpadates и монтировании в асинхронном режиме.

Измерения проводились на ноутбуке Toshiba Satellite Pro A40 с процессором Pentium-4/2,66 (Mobile), 512 Мбайт памяти, ATA-100 винчестером неизвестного происхождения (ни одна из утилит имени производителя мне так и не открыла) объемом 40 Гбайт, со скоростью вращения 4200 об./мин. В качестве "пробы пера", как и ранее, выполнялись следующие операции:

• копирование массива смешанных данных общим объемом 830 Мбайт;
• распаковка и копирование дерева портов FreeBSD (объемом около 25 Мбайт);
• копирование avi-файла размером 693 Мбайт.

Тесты для Ext2fs и ReiserFS проводились под управлением операционной системы Linux (дистрибутив Archlinux, ядро 2.6.8.1, установленное из умолчального бинарного пакета), для UFS - под DragonFlyBSD (октябрьский снапшот 2CSNAP-20041021-1130-GCC3, собранный с gcc3.4.1, ядро GENERIC).

Тесты осуществлялись на специально выделенном разделе объемом 5 Гбайт, на котором последовательно создавались файловые системы: Ext2fs, ReiserFS (для сравнения) и UFS. Для последней замеры проводились при включенном и отключенном механизме SoftUpadates. В последнем случае файловая система монтировалась в двух режимах: сначала умолчальном, частично асинхронному (опция noasync), а затем - чисто асинхронному (опция async). О смысле этих опций говорилось в одной из предыдущих заметок, а механизм SoftUpadates был описан в книге "Доступный Unix">. В каждых условиях все три теста выполнялись трижды (с размонтированием файловой системы в промежутке), за итоговый результат принималось среднее арифметическое. Что и можно видеть в таблице (результаты в секундах).

Тест	Работа с данными		Работа с портами			Большой файл
File Systems	Copy	Delete	Untar	Copy	Delete	Copy
Ext2fs	136	9	36	189	39	98
ReiserFS	150	3	46	96	30	95
UFS, noasync	393	49	271	356	258	115
UFS, async	252	14	74	129	69	116
UFS, SoftUp	274	15	235	339	188	115

Результаты измерений, которые можно видеть также на рисунке, несколько отличаются от полученных ранее. Что можно связывать с тем, что на низкоскоростном "железе" (напомню, речь идет о медленном ноутбучном винчестере) детали реализации конкретных файловых систем оказываются менее значимыми.

Рисунок. Результаты измерения быстродействия

Чтобы более не возвращаться к этому вопросу, начну с копирования большого файла. Тут мы видим распадение результатов на две группы: обе файловые системы Linux (лучшие, но практически равные, результаты) и все вариации на тему UFS (результаты столь же ровные, но на 15-20% худшие). Очевидно, это можно связать не столько с устройством файловых систем, сколько с быстродействием ATA-интерфейса в этих операционках.

В работе с массивом смешанных данных, как и ранее, чемпионом оказывается Ext2fs, за которой вплотную следует ReiserFS. В группе UFS-тестов характерен провальный результат этой файловой системы без задействования SoftUpdates, смонтированной в частично синхронном режиме. Чисто асинхронный режим демонстрирует некоторое превосходство над механизмом SoftUpdates - впрочем, не столь уж принципиальное.

Вполне предсказуемо, что во всем блеске асинхронный режим UFS проявляется на работе с портами - то есть огромным количеством очень маленьких файлов. Тут она не только более чем вдвое выигрывает у механизма SoftUpdates, но и (спешите видеть, впервые в мировой истории!) вполне значимо опережает Ext2fs на операции копирования. Хотя до ReiserFS и не дотягивает - ведь это коронный номер последней.

В общем, можно констатировать, что отказ от SoftUpdates в сочетании с асинхронным монтированием несколько повышает быстродействие файловых операций на UFS. Конечно, это влечет за собой и снижение надежности файловой системы. А поскольку никаких механизмов журналирования для UFS нет и не предвидится, последний фактор является определяющим для серверных применений. На пользовательском же десктопе, снабженном бесперебойником (а последний, ИМХО, должен являться непременным атрибутом нормальной Unix-машины), это не столь критично. Конечно, монтировать в асинхронном режиме корневую файловую систему не стоит. Да и не имеет смысла - по нормальному она изменяется только при реинсталляции ядра. Однако для таких ветвей файловой системы, как /usr/src, /usr/obj, /usr/ports, /usr/ports/distfiles, асинхронное монтирование видится вполне подходящим. Конечно, наибольший эффект оно дало бы для каталога /home. Однако тут каждый должен решать для себя сам - рисковать ли хоть ничтожным шансом на разрушение файловой системы ради быстродействия, или нет.

UFS2 на ccd: продолжение банкета с быстродействием

2004 г

Должен сказать, что результаты, изложенные в прошлой заметке на тему быстродействия файловых систем, меня несколько обескуражили. И главное, возник вопрос: если, как в старом советском анекдоте, с быстродействием UFS2 все так плохо, то почему же на самом деле с ним все так хорошо?

Иными словами, визуально при работе я, конечно, видел, что UFS2 медленнее всех когда-либо реально применявшиеся файловых систем для Linux. Но уж далеко не настолько, как получалось по результатам измерений.

И тут я сообразил, что реально-то я работаю не совсем в той конфигурации, которая была описана в той заметке. Потому что на самом деле в моей машине живет еще два диска - Seagate Barracuda IV, по 80 Гбайт каждый, объединенные в программный RAID нулевого уровня (strip) посредством ccd; просто на время тестирования они были отключены физически. И я решил посмотреть - а дает ли это что-нибудь в плане быстродействия.

Итак, методика измерений осталась прежней, объекты для манипулирования - также. А из железа добавились два вышеперечисленных винчестера, один - слейвом на первом IDE-канале (в паре с 40-гигабайтником, несущим систему), другой - мастером на втором. На них размещались: вначале по гигабайтному swap-разделу, далее - по разделу 4.2BSD, размером 20 и 60 Гбайт на каждом.

Двадцатигигабайтные разделы были объединены в ccd-устройство со стриппингом, под UFS2, монтировавшееся в качестве /usr/ports/distfiles - о нем далее речи не будет. А 60-гигабайтные разделы составили еще один программный ccd-RAID, также с расслоением (размер блока - 128 Кбайт, примерная методика описана в одной из моих заметок по FreeBSD). Объединенный раздел с UFS2 монтировался у меня в обычном состоянии как /home и нес на себе все данные, с которыми я постоянно работаю (средняя заполненость - около 70%).

Перед началом измерений файловая система /home была размонтирована и смонтирована как /mnt/hd. Как и в прошлый раз, последовательно выполнялись копирование массива данных и его удаление, развертывание, копирование и удаление дерева портов, копирование и удаление большого avi-файла. После каждого цикла файловая система размонтировалась, перемонтировалась заново и измерения повторялись - всего троекратно, в качестве результатов принимались средние значения.

Создавать на ccd специальный раздел специально для тестирования у меня возможности не было, поэтому все действия (копирование массива данных, развертывание и копирование дерева портов, копирование большого файла) выполнялись прямо в рабочем разделе. Что, конечно, оказывало некоторое (из общих соображение - негативное) влияние на результаты. Тем не менее, как можно видеть из таблиц 1 и 2, они оказались весьма показательными. Для большей наглядности я разделил данные для копирования/"растаривания" и для удаления. В качестве предмета сравнения выступили результаты для UFS2 и Ext2fs из прошлой заметки - обе в "умолчальных" режимах на 5-гигабайтном разделе одиночного диска.

Таблица 1. Копирование и "растаривание"

FS+Mode	Data	Untar	Ports	Big
UFS,default	211	189	255	104
UFS,ccd	185	107	175	83
Ext2,default	71	90	68	45

Сначала о копировании и "растаривании". Уже копирование массива данных дало более чем 10-процентный выигрыш в скорости против UFS2 на одиночном диске. При "растаривании" превосходство составило уже почти 50%, при копировании дерева портов - более 30%, и при копировании большого файла - более 20% (рис. 1).

Рис. 1. Копирование и "растаривание"

Результаты - не потрясающие воображения, но вполне весомые, а для "растаривания" уже сравнимые с ext2fs. Однако при удалении файлов все оказалось еще интересней (см. табл. 2).

Таблица 2. Удаление

FS+Mode	Data	Ports
UFS,default	7	92
UFS,ccd	5	34
UFS,ccd	5	34

Удаление массива данных с ccd-раздела происходило быстрее, чем с единичного UFS2, и даже чем с раздела ext2fs - хотя, при столь низких абсолютных значениях их трудно считать статистически значимыми. А вот на удалении дерева портов выигрыш во времени составил более 60% (рис. 2). Удаление же единичного файла происходило практически мгновенно и потому время его здесь не приводится.

Рис. 2. Удаление

Таким образом, на типично пользовательских задачах использование программного RAID со стриппингом (по крайней мере, в исполнении ccd, для vinum данных у меня, по понятным причинам, нет) дает вполне реальный (а иногда и просто значительный) прирост в быстродействии файловых операций. А поскольку нынче редкая мама не оснащается дополнительным IDE-контроллером, появляется возможность разнести винчестеры на отдельные линии (даже без задействования аппаратного ATA RAID), что должно еще более улучшить результаты.

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

FreeBSD vs Linux: быстродействие файловых систем

2004 г

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

Цели и задачи

Сначала я ставил себе очень ограниченную задачу - измерить быстродействие современной файловой системы FreeBSD - UFS2 - в разных режимах монтирования. Как известно, по умолчанию она монтируется в т.н. режиме noasync, при котором изменения метаданных файлов записываются на диск синхронно, а для собственно данных применяется асинхронная запись, то есть кэширование. Что изначально ставит UFS2 в невыгодное (с точки зрения быстродействия) положение по сравнению с Linux, где по умолчанию для большинства файловых систем, поддерживаемых этой операционкой в качестве нативных, принят чисто асинхронный режим - с кэшированием не только данных, но и метаданных.

Однако теоретически чисто асинхронный режим существует и во FreeBSD, хотя использование его крайне не рекомендуется во всех официальных документах проекта, как способствующее падению надежности. Что, безусловно, верно для серверов, но не кажется столь уж критичным для десктопов, оснащенных бесперебойниками (а бесперебойник, по моему скромному мнению, - непременный атрибут любой Unix-машины, особенно в условиях постсоветской действительности). Так что возникло естественное желание - поглядеть, а как ведет себя UFS2 в асинхронном режиме.

Сразу замечу, что первые же результаты измерений оказались несколько неожиданными и, по крайней мере для меня - не вполне понятными. И потому для прояснения ситуации я решил сравнить их с проведенными в аналогичных условиях измерениями для ext2fs в Linux. Ну а дальше - больше, стало интересным сопоставление с прочими файловыми системами Linux. И, наконец, возник вопрос, а как эти операционки работают с файловыми системами друг друга. Поскольку поддержка в Linux UFS2 ныне не реализована (да и включить поддержку UFS просто - задача не тривиальная), пришлось ограничиться измерениями только для ext2fs под FreeBSD. Таким образом и определились

Участники тестирования

Итак, первым участником, естественно, стала UFS2, образованная с параметрами по умолчанию sysinstall (размер блока - 16384 байт, размер фрагмента - 2048), с предусмотренным этой утилитой включением режима SoftUpdates. И монтируемая в умолчальном же, то есть частично асинхронном (опция -o noasync, принимаемая по умолчанию при исполнении команды mount) режиме.

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

В качестве объектов сравнения выступили нативные файловые системы Linux. В первую голову это, конечно, была классическая ext2fs, монтировавшаяся в двух режимах - умолчальном и в режиме -o noatime.

Затем - ее журналируемый вариант, ext3fs. Для нее штатно предусмотрено три режима использования - полного журналирования (опция -o data=journal), при котором фиксируются операции не только с метаданными файлов, но и их данными, стандартного частичного журналирования (опция -o data=ordered, при которой данные и метаданные группируются в единый блок транзакции) и режима writeback, в котором никакого журналирования данных не осуществляется. От использования опции -o noatime я в данном случае отказался (честно говоря, просто из лени - хотя, как стало ясным из результатов, ничего принципиально нового эта опция не дала бы).

Далее - ReiserFS, самая претенциозная (и, пожалуй, наиболее популярная среди пользователей Linux) журналируемая файловая система. Здесь, кроме умолчального, я снова опробовал режим с отказом от обновления atime - и, как показала практика, не напрасно).

Аналогично я поступил и с XFS - измерения на ней производились в умолчальном режиме и в режиме с опцией -o noatime. И, наконец, в отношении JFS я ограничился режимом по умолчанию - так как этой системой никогда практически не пользовался, мало чего о ней знаю и привлек ее к делу исключительно для сравнения.

Все файловые системы создавались посредством соответствующих утилит (mke2fs - для ext2fs и ext3fs, mkreiserfs и mk.xfs - для одноименных файловых систем, jfs_mkfs - для JFS) с параметрами по умолчанию. Исключением стала XFS, для которой размер allocation group и объем журнала были подобраны в соответствие с рекомендациями Дэниэла Роббинса (объем журнала - 32 Мбайт, минимум одна allocation group на 4 Гбайт дискового пространства, отводимого под эту файловую систему).

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

О тестовой платформе

Измерения производились на подручном железе, каковое содержало:

• процессор Pentium-4/2,53 Ггц, FSB 533, без HT;
• материнская плата Albatron PX845PE на одноименном чипсете, в варианте с дополнительным контроллером ATA RAID/SerialATA Promise FastTrack 376 (впрочем, не задействованным);
• 1 Гбайт оперативной памяти (2x512 PC-2700, продававшейся под брэндом "якобы Samsung");
• жесткий диск Seagate Barracuda IV 40 Гбайт, интерфейс ParallelATA, 7200 об./мин., подключенный как single на 1-й канал стандартного ATA-контроллера из южного моста ICH4.

Прочие компоненты, типа CD-ROM (single на втором IDE-канале), значения в данном случае не имеют.

На диске имелось 4 первичный раздела. Первый, объемом 30 Мбайт с файловой системой ext2fs, исполнял функции загрузочного и нес на себе только GRUB (и ядро Linux). Второй раздел был определен как BSD-слайс, и в нем, на файловой системе UFS2, размещалась FreeBSD 5.2.1. Третий раздел был объявлен DOS Extended и нес на себе Archlinux 0.6 (ядро 2.6.6). Детали их разбиения, а также файловые системы, в данном контексте не существенны.

Во о избежание недоразумений замечу, что в обеих ОС диск функционировал в штатном режиме UDMA100, что определялось утилитами atacontrol во FreeBSD и hdparm в Linux.

И еще: FreeBSD была подвергнута процедуре make world с флагами оптимизации -O1 и -march=pentium4. Ядро, пересобранное на базе очень облегченного GENERIC (с исключением поддержки всего отсутствующего, типа SCSI и сетевых карт), компилировалось с флагом -O2 под тот же Pentium-4. Для Archlinux использовалось штатное прекомпилированное (из репозитория проекта - current) ядро, собранное, как и вся система в целом, с флагами -O2 -march=i686.

Впрочем, все сказанное в предыдущем абзаце вряд ли способно было кардинально повлиять на производительность при файловых операциях. И потому для нас важен только четвертый первичный раздел, объемом 5,5 Гбайт, который и подвергался всяческим издевательствам. Для чего на нем, после присвоения соответствующего идентификатора (4.2BSD или Linux native, соответственно), на нем создавались перечисленные в предыдущем разделе файловые системы, которые монтировались с указанными опциями. А на них уже помещались те данные, которые представляли собой

Объекты тестирования

Измерения я затевал для личных целей, и потому меня больше всего интересовали операции с теми данными, с которым я имею дело регулярно. А это а) массивы смешанных данных (тексты и иллюстрирующая их графика), б) массивы из огромного количества очень маленьких файлов (типа дерева портов FreeBSD и аналогичных систем управления пакетами из Source Based дистрибутивов Linux) и в) большие файлы, от объема CD и выше. В соответствие с этим я и подобрал тестовые объекты.

Во-первых, это был каталог моих рабочих материалов - файлов в форматах plain text и html с иллюстрациями в форматах gif, tiff, jpeg, png, объем которых варьировал от нескольких килобайт до первых десятков мегабайт. Для оживления картины я разбавил его звуковыми файлами mpeg (от 1,5 до 6 Мбайт каждый). В результате первый тестовый массив суммарно составил 830 Мбайт.

Вторым объектом было подручное дерево портов FreeBSD от 6 мая 2004 г., объемом 24,2 Мбайт, и результат его "растаривания", что давало каталог в 124 Мбайт. Специфика его - в том, что он образован огромным (свыше 100 тысяч) количество файлов, преобладающий размер которых - несколько сот байт.

Наконец, третьим объектом стал avi-файл размером в CD - 693 Мбайт.

Ничего лучшего, чем измерять время копирования этих массивов, я не придумал. То есть каталог данных копировался командой вида

$ cp data newdata

с последующим уничтожением целевого каталога

$ rm -Rf newdata

и замеров времени каждой операции посредством вывода команды date до и после нее. Аналогично я поступал и с большим файлом. А тарбалл портов предварительно разворачивался командой

$ tar xzvf ports.tar.gz

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

date >> file_of_result &&
command1 &&
date >> file_of_result &&
...
date >> file_of_result &&

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

Результаты

Результаты измерений скорости выполнения всех операций над тремя объектами приведены в таблице и на рис. 1-3. Единицы измерения - секунды, соответственно, меньшие значения везде отвечают лучшим показателям. Которые мы и рассмотрим последовательно для всех файловых систем.

UFS

Начнем с той, что послужила первопричиной этой заметки - с UFS2. Напомню, что она монтировалась последовательно в четырех режимах - умолчальном, с включением опции -o noatime, в чисто асинхронном режиме (опция -o async) и, наконец, с включением обеих этих опций. Теоретически рассуждая, в этом порядке и должно возрастать быстродействие файловых операций. Что же мы видим на практике?

Таблица. Результаты измерения (в сек.) быстродействия файловых операций в различных файловых системах

Тест	Работа с данными		Работа с портами			Большой файл
FS+Mode	Copy	Delete	Untar	Copy	Delete	Copy	Delete
UFS,default	211	7	189	255	92	104	0
UFS,noatime	210	7	194	333	99	102	0
UFS,async	211	8	201	352	99	103	0
UFS,both	209	6	202	344	98	103	0
Ext2,FreeBSD	222	25	280	309	222	150	1
Ext2,default	71	6	90	68	7	45	0
Ext2,noatime	73	6	93	68	7	46	0
Ext3,journal	123	6	134	58	6	98	1
Ext3,ordered	81	15	107	115	17	50	16
Ext3,writeback	91	7	107	68	51	53	1
Reiser,default	100	2	59	51	7	44	1
Reiser,noatime	89	2	71	26	7	47	1
XFS,default	95	9	76	83	41	48	0
XFS,noatime	97	9	80	74	42	49	0
JFS,default	132	13	267	160	19	91	0

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

Рис. 1. Работа с массивом смешанных данных

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

Рис. 2. Работа с деревом портов

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

Рис. 3. Работа с большим файлом

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

Минус этого - то, что резервов повышения быстродействия файловых операций во FreeBSD обнаружить не удается. Посмотрим же теперь, что мы теряем, отказываясь в ее пользу от Linux с его многочисленными файловыми системами.

Ext2fs

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

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

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

В общем, приходится с прискорбием констатировать, что в плане быстродействия UFS2 и близко не лежала с ext2fs, чем бы это ни объяснялось (desktop-пользователю эти объяснения по большому счету до лампочки). И потому интересно посмотреть, а не проявит ли себя ext2fs со столь же хорошей стороны также и во FreeBSD?

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

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

Ext3fs

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

Вопросы надежности мы здесь не обсуждаем, а вот что касается быстродействия... При копировании массива смешанных данных режим journal действительно оказывается наиболее медленным, однако первенство остается за режимом ordered (а не writeback, как следовало бы ожидать). А вот стирание результатов этого копирования вообще показывает парадоксальную картину: если при режимах journal и writeback скорость удаления каталога ожидаемо быстра (практически такая же, как в ext2fs), то в режиме ordered эта процедура выполняется просто неприлично медленно (15 секунд против 6-7, как можно видеть из таблицы).

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

Дальше - больше: график скоростей удаления дерева портов просто обратен теоретически ожидаемому: блестящий результат в режиме полного журналирования (6 секунд - чуть не лучше, чем для ext2fs), посредственный (17 секунд) - в режиме ordered, и наихудший для всех файловых систем Linux (51 секунда) - в якобы быстрейшем режиме writeback.

Наконец, обращение с большим файлом дает нам очередную (уже ожидаемую) неожиданность: распределение скоростей копирования повторяет таковое для дерева портов (лучший результат - в режиме ordered, похуже, но близкий - в режиме writeback, и существенно худший - в режиме journal, 50, 53 и 98 секунд, соответственно). Но зато при удалении этого самого большого файла режим ordered отличился как никто: в нем эта процедура заняла аж 16 секунд. Не просто хуже всех, а недосягаемо хуже. И еще раз подчеркну, что речь идет не о случайном всплеске, а о среднем из трех измерений, разделенных перемонтированием файловой системы.

Как будет видно из дальнейшего, ext3fs с точки зрения быстродействия вообще смотрится бледновато на фоне прочих файловых систем, с которыми работает Linux. Но против FreeBSD она все равно сохраняет преимущество по всем позициям: усилиями всех трех режимов журналирования изначальную ext2fs не удается низвести до уровня частично синхронной UFS2. И даже худший результат ext3fs при работе с портами остается недосягаемых для той ОС, в которой сама идея портов появилась впервые.

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

ReiserFS

Эта файловая система изначально проектировалась (в том числе и) для эффективного обращения с большим количеством маленьких файлов - в частности, экономии занимаемого ими пространства для. Однако сейчас нас интересует быстродействие - и для всех файлов вообще. Так что начнем с массива смешанных данных.

И тут мы впервые видим торжество теоретических предсказаний: умеренное быстродействие при копировании нашего массива в режиме по умолчанию увеличивается на 10% при включении режима noatime - со 100 секунд до 89 (хотя и не достигает рекордного). Но зато рекорд бьет удаление копируемого массива - по 2 секунды в каждом из режимов.

Дерево портов... Превосходные результаты при "растаривании" и копировании в умолчальном режиме. При отмене обновления atime в первом случае они несколько ухудшаются. Но зато - браво - копирование с этой опцией осуществляется практически вдвое быстрее, чем без нее; такого результата мы еще не видели. И опять ReiserFS близок к рекорду при удалении портового безобразия - финишируя голова в голову с ext2fs.

И последняя неожиданность от детища Ханса Райзера - в копировании большого файла оно показывает себя в числе лучших, хотя тут влияние noatime и не сказывается. Посмотрим, сможет ли потягаться с этим XFS, которая, напротив, по замыслу предполагалась именно для хранения мультимедийной информации.

XFS

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

Работа с портами - на среднем уровне в отношении "растаривания" и копирования. И - неожиданно большое время удаления дерева портов (более 40 секунд), приближающееся к "анти-рекорду" writeback-режима ext3fs (хотя все равно много лучшее, чем для UFS2).

А вот результат по большому файлу (48-49 секунд) - не порадовал: хотя он и в числе лучших, но от "мультимедийной" файловой системы я ожидал большего. Хотя, может быть, с точки зрения SGI, это 700 Мбайт - это отнюдь не много? И в утешение - провала при удалении большого файла также не отмечается:-).

JFS

Эпоним журналируемых файловых систем выступает в нашем зачете вне конкурса - причинам, о которых говорил выше. И результаты показали, что это было вполне оправданно. Ибо мы имеем:

• худший среди всех файловых систем Linux результат в копировании смешанного массива и второй с конца (после провала ordered-режима etx2fs) - в его удалении;
• худший результат "растаривания" среди всех нативных файловых систем вообще, включая UFS2; хуже оказалась только ext2fs из под FreeBSD - но ведь с чужака и взятки гладки;
• прямо скажем, не блестящее время удаления дерева портов;
• копирование большого файла - финиш в плотной группе отстающих.

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

Выводы

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

В частности, я всегда подозревал, что обе файловые системы FreeBSD - и старая UFS, и новая UFS2, - уступаю своим Linux'овым сестрам в быстродействии. Да это обычно видно и, что называется, органолептически. Однако я никак не ожидал, что для UFS2 в количественном отношении отставание окажется столь существенным. Должен заметить - выполнявшиеся мной ранее измерения для UFS просто столь разительной тормознутости не показывали - даже в отношении ext2fs (для ReiserFS меньший разрыв можно было бы объяснить младенческим тогда ее возрастом). Не исключено, что это - расплата и за 64-битную адресацию, и за вдвое увеличенные inodes...

Далее, я не ожидал столь достойных результатов ReiserFS не только в отношении очень маленьких файлов, но и во всех остальных тестах. Так что беру назад все не очень хорошие слова, которые ранее говорил в ее адрес. Правда, непроверенным осталось эмпирически наблюдаемое (но не подтверждавшееся количественно) явление падения ее производительности на больших (более 100 Гбайт) разделах, размещенных на программном RAID - но для многих ли desktop-пользователей это актуально?

Не показала себя в ожидавшемся блеске и столь любимая мною раньше XFS. Все же мало когда приходится работать с файлами более объема сидюшника, а в этих пределах она оказалась не быстрее ReiserFS.

А вот в чем измерения меня укрепили - так это в предубежденном (и неблагоприятном) отношении к ext3fs. И дело даже не в том, что хоть каком-нибудь ее режим "отличился" хотя бы на одном тесте. Недовольство вызывает именно непредсказуемость ее поведения в зависимости от режима и характера данных. Вероятно, разработчики имели основания для заключения об оптимальности режима ordered - однако основывались они, судя по всему, на задачах серверных, но отнюдь не десктопных.

Так какую же файловую систему выбрать простому настольному пользователю для своей отдельно взятой персоналки? Мой ответ не будет блистать оригинальностью, если я заявлю со всей определенностью: каждому овощу - свой фрукт. И бесполезно пытаться найти систему, одинаков быструю и для хранения дерева портов (или их Linux-аналогов), и для сборки iso-образов под резервное копирование, и прочая, и прочая, и прочая.

К счастью, пользователь FreeBSD избавлен от этих терзаний - UFS и UFS2 суть объективные реальности, данные ему в ощущениях берклианских разработчиков. Только он должен понимать, что по крайней мере при работе с файлами ему придется поступиться быстродействием ради стройности и аккуратности используемой системы. Впрочем, не компенсируется ли потеря времени на копировании файлов отсутствием мытарств с несовпадением версий библиотек или компиляторов?

А вот пользователю Linux есть над чем поломать голову. Потому что однозначно я не рекомендовал бы к употреблению только JFS - да и то, не факт, что, прочитав многопудовую документацию к ней, я был бы столь категоричен (другое дело, что пока ни одна из особенностей этой файловой системы не способна подвигнуть меня на такое чтение, тем более по англицки).

Ибо даже нелюбимой мною ext3fs можно найти применение. В частности, для корневой файловой системы в том случае, когда из нее в отдельные ветви вынесены /var, /usr, /opt (если в данном дистрибутиве задействуется активно), и, конечно же, /home.

Для первых трех ветвей подходящей видится ReiserFS. Особенно если у нас - Source Based дистрибутив, использующий какую-либо портообразную систему. И к слову - идеальной она окажется именно тогда, когда дерево этих портоидов вынесено в отдельную ветвь внутри /usr или /var. А еще измерения склонили меня к мысли, что и для /home ReiserFS более чем пригодна - раньше я ничего, кроме XFS, в этом качестве не признавал. Хотя и теперь не вижу причин, почему бы благородному дону не размещать на XFS свои данные - особенно если он не имеет привычки часто и в большом количестве их удалять.

Наконец, ext2fs - отнюдь не худший выбор для многих пользователей, не желающих заморачиваться созданием множества разделов и подбором под них идеальных файловых систем (при условии наличия бесперебойника, разумеется). И уж совсем незаменимой она оказывается а) для обмена данными с установленной на той же машине FreeBSD, и б) для раздела /boot в случае использования мультизагрузчика GRUB. Так что и старушку ext2fs рано еще списывать в тираж...