Блогосайт Alv’а. О Unix'ах, былом и грядущем

Сделал себе новый полу-сайт, полу-блог:
http://alv.me/
Это всё-таки поприличней выглядит.
Постепенно перетащу туда весь контент отсюда и с http://alv-aka-fedorchuk.blogspot.com/

Наброски к книге. 2. Настраиваем HAL

Кроме описанного ранее, есть и более радикальный метод настройки монтирования сменных носителей от лица пользователя -- использование механизма HAL (Hardware Abstraction Level). Правда, работает он только в Иксах, насколько мне известно, точно -- в интегрированных средах KDE, GNOME и Xfce, за менеджеры окон не скажу по незнанию; хотя, судя по тому, что порт hal идёт в качестве зависимости X-сервера, вероятно, и в некоторых из них этот механизм также поддерживается.

Итак, для начала необходимо установить соответствующий порт -- /usr/ports/sysutils/hal. Правда, как только что было сказано, при установке Иксов и какой-либо из интегрированных сред он уже будет инсталлирован как зависимость, причём вместе с графическим фронт-эндом к нему (в случае с GNOME и Xfce это будет порт /usr/ports/sysutils/gnome-mount).

Теперь -- собственно настройка. Она проста как грабли: отправляемся в каталог /usr/local/etc/PolicyKit и обнаруживаем там файл PolicyKit.conf. По умолчанию содержимое его следующее:

<config version="0.1">
   <match user="root">
   <return result="yes"/>
   </match>
   <define_admin_auth group="wheel"/>
</config>

Что предваряется следующей фразой:

<!-- See the manual page PolicyKit.conf(5) for file format -->

Руководствуясь man (5) PolicyKit.conf, между

    <define_admin_auth group="wheel"/>

и

</config>

дописываем следующие строки:

    <match action="org.freedesktop.hal.storage.mount-removable">
             <return result="yes"/>
   </match>
   <match action="org.freedesktop.hal.storage.mount-fixed">
              <return result="yes"/>
   </match>

разрешающие членам группы wheel монтирование сменных и внутренних носителей, соответственно.

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

Наброски к книге. 1. Монтирование сменных устройств

Начинающих пользователей FreeBSD, имеющих опыт работы в современных дистрибутивах Linux'а, часто раздражает необходимость получать права администратора для монтирования сменных накопителей (компакт-диски, флэшки, носители цифровых камер). И по умолчанию это действительно так, и попытки решить эту задачу простым редактированием файла /etc/fstab по образу и подобию Linux'ового успеха иметь не будут -- опция user, обеспечивающая эту функцию в последней ОС, командой mount из FreeBSD не поддерживается.

И тем не менее необходимость административных прав для монтирования сменных устройств во FreeBSD -- кажущаяся. Вот только для реализации права юзера на монтирование потребуются несколько иные действия.

Для начала, получив привилегии root'а, устанавливаем права доступа к файлам сменных устройств в файле /etc/devfs.conf, отвечающем за поведение файловой системы devfs:

perm    /dev/cd0     0666
perm    /dev/xpt0    0666
perm    /dev/pass0   0666
perm    /dev/da0  0666
perm    /dev/da0s1   0666

Заодно тут же снимаем символ комментария со строки

#link    acd0    cdrom

Благодаря этому при создании devfs (а она, как известно, пересоздаётся при каждом рестарте машины) будет устанавливаться символическая ссылка для файла /dev/cdrom (такое имя привода компакт-диска желают видеть некоторые программы, например, mplayer) на файл реального устройства acd0.

Затем в файле /ect/sysctl.conf разрешаем монтирование VFS от имени обычного пользователя:

vfs.usermount=1

Теперь возвращаем себе права обычного пользователя и от его имени создаём в домашнем каталоге точки монтирования для сменных устройств:

% mkdir ~/cdrom ~/usb

Проверяем правильность настроек командами:

% /sbin/mount -t vfat /dev/da0s1 ~/usb
% /sbin/mount -t cd9660 -o ro /dev/da0s1 ~/cdrom

Если монтирование проходит нормально, то вносим в файл /etc/fstab соответствующие строки:

/dev/acd0 /home/username/cdrom cd9660 ro,noauto 0 0
/dev/da0s1 /home/username/usb vfat rw,noauto 0 0

Однако возможно, что после всех предпринятых шагов флэшка или компакт откужутся монтироваться от лица пользователя, выдав предупреждение, что

Operation not permitted

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

Первое решение -- это (от лица суперпользователя) присвоить командам /sbin/mount и /sbin/umount так называемый бит суидности:

# chmod a+s /sbin/mount /sbin/umount

Не очень изящно, но, говорят, работает.

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

#!/bin/sh
mount /cdrom;  umount /cdrom
mount /mnt; umount /mnt

который поместить в каталог /usr/local/etc/rc.d/ под именем, например, mount_umount.sh. Наличие компакта в приводе или флэшки, подсоединённой к USB-порту, не обязательно.

Мне с такой ситуацией сталкиваться не пришлось, поэтому не опробовал ни первый, ни второй способы. Но, по сведениям, работают оба.

Хроника блога. 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, рассчитываю в ближайшее время исследовать и этот вопрос.