Примета:

Сделать 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-шное правило, что большие буквы отдельно, а маленькие - отдельно), а новый - такие шансы еще не потерял.