Читаю тут Гугл про Infiniband (по случаю вчерашнего поста) и внезапно выяснил, что 2-портовые карты на eBay продаются вообще по $22 (+ доставка, две карты получаются чуть меньше $100)

Так как я давно вынашиваю мысль поднять дома линк быстрее 1Gbit/s на небольшом пятачке вокруг рабочего стола, я сильно возбудился. Но есть вопросы:

1. Верно ли я понимаю, что CX4-кабель для Ethernet и Infiniband MicroGigaCN (как его называет Mellanox) и просто банальный 4xSAS (SFF-8470) - это все одно и то же?
2. Есть ли драйвера для Mellanox Infiniband под FreeBSD9? Или таки светит мне Linux на NAS?
3. Верно ли я понимаю, что взяв три 2-портовые карты (1-портовых нету) я могу 3 машины соединить в P2P-сеть и внутри каждой пары будут искомые 10G (после вычета оверхеда - 8G data)? В каждой паре заведу свою IP-подсеть, роутинга не надо. Что в такой конструкции будет с subnet manager, можно ли OpenSM-у сказать "этот интерфейс не твой"?

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

PHP:

1. У PHP база данных таймзон вшита в пузо и, конечно, не обновляется регулярно.
2. Но есть pecl-timezonedb, который ее оверрайдит, со свежей базой (последняя имеет номер версии 2011.13), с этим расширением с таймзонами все станет отлично и любимая всеми Europe/Moscow будет работать как полагается по новым правилам.
3. Но если вы живете под FreeBSD, то там /usr/ports/misc/pecl-timezonedb не обновлялся очень давно, посему:
   • Меняем там в Makefile 2010.9 на 2011.13
   • удаляем distinfo
   • make && make install
4. Добавляем timezonedb.so в список extensions.ini (на FreeBSD это сделает make install)
5. Перестартовываем PHP-fastcgi или Apache или что у вас там работает процесс-сервером для PHP
6. Ура, можно накатить первый стакан.

Drupal 6:

1. Сам по себе сразу начинает жить правильно (ну, насколько мне показалось). Т.е. таймзона меняется после апдейта PHP-timezonedb с +0300 на +0400 сама.
2. Но! В Administer-Date-and-time есть настройка про User Configurable time-zone. Если она включена, то пользователю будут показываться даты-времена в его таймзоне. И весь созданный им контент будет иметь время создания рассчитанное из юзерской таймзоны.
3. Но. Юзерская таймзона специфицирована в секундах смещения от UTC.
4. Выходов два: или для всех российских пользователей взять и поправить скриптом (по хорошему, с учетом даты регистрации), или просто отменить настройку пользовательских таймзон. Я пошел по второму пути.

Вынесу из каментов к прошлому посту:

номер раз:

Это значит что с дисковой/fs в линуксе все настолько загадочно и хреново, что у нас ротейт логов на одной из машин роняет ее регулярно раз в месяц (логи то ротейтятся мгновенно, только апач больше не работает) и помогает только reboot -fn. А на десктопе при копировании больших файлов все задумывается так что анекдот про "сейчас дискетка отформатируется..." как раз про современные Линуксовые ядра. Debian/2.6.разные, ext3/4.

номер два:

Я ловил клина на полминуты только при удалении больших пачек больщих файлов (ie по полгига где-то)

Типа записал жене сериал/дитю мультиков на болванку -- хочешь грохнуть исошку/исходники -- и оно тупит минуты две. В 2.6.39 xfs порефакторили сильно (осталась только его "родовая" болезнь -- файл при создании и до закрытия (или до fsync?) имеет только dnode, и если начать копировать файл (ту же исошку) и в середине дернуть питание -- файл будет пустой)

С другой стороны у меня 4 машины с XFS везде кроме /boot и убитого XFS я не видел еще (хотя питание у меня тут весьма нестабильное)

И, рискуя (стремясь!) спровоцировать Holy War, спрошу я вас: че, типа, так и есть?. И считается нормальным? Ну ладно, xfs вроде починили, но ведь было?

Update: в каментах сообщили правильное название, "баг 12309". Поиск в Яндексе "Linux 12309" приносит истинные лулзы!

Справедливости ради два пункта:

Если поискать в этом блоге, особенно в каментах, то найдете что ZFS на трех дисках (RAIDZ) давала у меня скорость чтения/записи порядка 75-80 Mb/sec. Так оно и было до недавнего времени, пока я с этой скоростью не уперся в скорость на сети (samba).

Пришлось навести следствие. Выяснилось очень простое, хотя и не вполне очевидное:

• У меня был даунклоченый Core2Duo: 1.86Ghz работающий на ~1.6, задаунклочил летом, по случаю жары, просто на всякий случай.
• При этом при чтении с ZFS system time как правило не рос выше 50%, что я неверно интерпретировал как однопоточность ZFS (судя по всему, неверно, ибо потом в тестах видел и 70% system) и верно интерпретировал как упертость в процессор.
• Банальный оверклок того же горшка (и памяти) приводил к почти линейному росту скорости FS.

Тогда я пошел в лабаз и купил там еще один 2TB диск и 3.06-гигагерцовый C2D (E7600), собрал все в кучку (дисков стало 4) и результат:

• 170-195 Mb/sec на запись
• 230-280 Mb/sec на чтение

Все тестирование делалось методом

dd if=/dev/zero of=file bs=1M count=20000
dd if=file of=/dev/null bs=1M

Если вы хотите поеба потрахаться по-настоящему, предлагаю такой вот метод:

• Создаете ZFS-том терабайт эдак на шесть (меньше не пробовал) на FreeBSD 8.1-RELEASE/STABLE.
• И записываете туда пару-тройку сотен тысяч файлов с русскими (и европейскими) именами в кодировке UTF-8.

Единственная выявленная система - это очень длинные, под лимит, имена файлов. Не только русские, но и европейские (с умляутами).

Примета:

Сделать zpool upgrade, но не сделать gpart bootcode ... -p gptzfsboot - означает поипаться от души поиметь немало веселых минут.

Особенно с учетом того, что zpool upgrade делается на лету, а отсутствие нужной версии boot loader становится заметно после перезагрузки. Которая у меня, например, случилась через две недели.

zroot on / (zfs, local)
zroot/home on /home (zfs, local)
zroot/tmp on /tmp (zfs, local, nosuid)
zroot/usr on /usr (zfs, local)
..... и еще с десяток томов под разные нужды....

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

В частности, расширять root pool нельзя, поэтому идея-фикс по переносу данных без многократного переписывания данных не проканала. А была она такая:

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

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

Бурное обсуждение моей предыдущей заметки про аппаратный RAID заставило меня потратить немножко времени в выходные на изучение software raid5 в FreeBSD (других подопытных ОС не оказалось).

Приборы и материалы

FreeBSD 7.1-PRERELEASE - i386, Core2Duo 1.86, 2GB RAM, 3 диска Western Digital WD7500AAKS (750Gb).

Диски я извлек из рабочей станции, там они показывали 140MB/sec на чтение и 120-125 на запись будучи прицеплеными к Areca ARC-1120 в режиме RAID5 под WinXP/Vista.

GEOM RAID5 все еще не входит в комплект FreeBSD, поэтому использовались две из трех имеющихся внешних реализаций: GEOM RAID5 TNG и GEOM RAID5 PP. Забегая вперед скажу, что существенной разницы в производительности я не увидел.

Помимо этого, я посмотрел на производительность RAID0 (GEOM stripe).

Тестирование проводилось на чтении-записи длинных файлов т.к. меня интересуют именно они. На коротких операциях всё может быть иначе, все "короткие" нагрузки настолько разные, что требуют тестирования по месту.

Давно собирался, но руки дошли только сейчас.
FreeBSD 6.3-STABLE, amd64, делаем make -j Ncpu buildworld

• Dual Opteron 275: 22 минуты (user time: 55 минут)
• Core2Quad, операционка запущена под VMWare, доступны два ядра: 31 минута (user time: 42 минуты)

Потерял полдня, прежде чем сложил все кубики в пирамидку (и то, не уверен что правильно).

Нужно: получить PHP5 с клиентом PosgreSQL (всякие прочие extensions на вырост), в виде апачевского модуля, все происходит под FreeBSD7.

• Apache 1.3, все собираем из ports - не работает. SIGSEGV где-то внутри инициализации pthreads, хотя никому из участников эти threads нафиг не нужны и непонятно кто их приволок. /usr/local/bin/php - работает.
• Apache 1.3, собираем PHP --with-pgsql - все работает, пока нет загружаемых extensions. Как только появляется хоть одно - падаем.
• Apache 2.2, собираем все из ports - работает.
• FreeBSD6 в этот раз не пробовал, но когда в прошлый раз пробовал - работало.

Получается, из-за скромненькой фигулинки всем проектам показан переезд под Apache2 ? И mod_perl2 ? А mod_perl2 небось тоже не работает ?

MySQL не предлагать. С Apache я совладаю как-нибудь, а два сервера баз данных в моей жизни - это уже перебор. Снести семерку тоже не предлагать, UFS2 на терабайтных FS - уже перебор.

Несколько дней назад я опубликовал исходник LC_COLLATE для кодировки ru_RU.UTF-8 для использования в FreeBSD. Там же я обещал, что если понадобится не "универсальная" сортировка, а такая же, как в FreeBSD, то сделаю и ее, а обещания нужно выполнять.

Помимо этого, старый вариант не имел вообще никаких шансов попасть в FreeBSD (причины этого мне объяснил Андрей Чернов: нарушается FreeBSD-шное правило, что большие буквы отдельно, а маленькие - отдельно), а новый - такие шансы еще не потерял.