А затем: ln /sbin/shutdown /sbin/poweroff :)
ln /sbin/shutdown /sbin/poweroff
/sbin/
ко-ко-ко, я лялексодаун

это процесс переноса данных с одного носителя на другой в случае замены диска. Что в случае простого pool (stripe) без физической замены диска невозможно (ну, то есть я понял бы был бы миррор - и данные бы сначала надо было на второй Hdd сбросить, а потом проводить скраб), а физической замены не было. Т.е. - что система делала около часа с хардом - я не понял.

Пул типа stripe?

resilvering, скорее всего, выполнялся для оптимизации пространства внутри пула. Также возможно, что на одном из носителей ZFS обнаружила BAD-блоки и перенесла данные на другой носитель во избежание полной потери данных из-за деградации одного из носителей в страйпе.

Неплохо бы пустить smartctl (sysutils/smartmontools) по всем дискам в пуле и посмотреть на статистику. Более радикальное средство оценки записывающей способности — MHDD.

Я помнится пробовал 4.x, 6.2, какой-то еще, 9ку - и все эти релизы имели серьезные проблемы. Причем там, где в Linux не было проблем. Добавить к этому никакой срок поддержки релизов. Скажем дружно: Нафиг нужно!

Ради справедливости надо сказать, что в gentoo с этим дело обстоит не хуже и не медленеее (распаковка готового stage4, последних портежей, grub) - 3-15 минут в зависимости от размера стейджа. Мой персональный stage4, включающий портежи, grub и все необходимые программы имеет несжатый размер 2,95Гб и устанавливается ну очень быстро ~2-3 минуты. Ежели есть опыт и готовый stage4, это можно выполнить набрав несколько команд вручную или воспользоваться calculate-linux для развертывания системы ~15-20 минут (тут даже новичок справится).

Значит ты что-то не то и не туда ставил. make собирает систему и программы из портов по умолчанию с ключом -O2.

А я девятку уже месяц как с -O3 обновляю, ядро правда только с -O2 собирается.

Мне бы вот такой изврат задействовать:

-g0 -O3 -march=atom -mtune=atom -mmmx -mssse3 -mfpmath=sse -fmerge-all-constants -fno-gcse -funroll-all-loops -fno-tree-pre -fno-tree-forwprop -fno-cprop-registers -fno-predictive-commoning -fno-inline-functions-called-once -funsafe-loop-optimizations -fno-tree-vectorize -fomit-frame-pointer -pipe

Тогда я мог бы сравнить производительность gentoo vs freebsd vs dragonfly в одинаковых условиях, если добрые люди надоумят как это в bsd делается правильно. На gentoo в gcc-4.5.3-r2 с этими флагами мною собираются почти все пакеты, которые не вылетают за пределы разумных границ при сборке.

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

Вариант ядра Preemptible Kernel и модули собираются с

CFLAGS_MODULE   = -O2 -march=atom -mtune=atom -fmerge-all-constants -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -fipa-cp-clone -fno-gcse
CFLAGS_KERNEL    = -O2 -march=atom -mtune=atom -fmerge-all-constants -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -fipa-cp-clone -fno-gcse

А ядро Voluntary Kernel Preemption можно собрать и вовсе заменив -O2 на -O3.

Профит для процессоров atom приличный.

А на пробу какую версию рекомендовали бы?

PC-BSD 9.0

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

А как она (UFS2) vs EXT3/4 по скорости? Без подкола, интересно просто - давно Фряху не ставил.

В /etc/make.conf впиши:

CFLAGS= -O2 -pipe -mtune=atom

Вообще же, попробуй заменить компилятор на более свежий, скажем, на GCC 4.6.4 (порт lang/gcc46). Краткая инструкция по переходу на новый компилятор: http://www.freebsd.org/doc/ru/articles/custom-gcc/article.html Новый компилятор поддерживает куда больше возможностей по оптимизациям.

Поставь и узнаешь.

Спасибо, добрый дяденька.

Радует поддержка ZFS, хочется только чтобы и инсталлятор умел её. Про девятку тут посты были - это просто давняя традиция фряхи, нулевые релизы считаются ... ну так себе стабильными, да и х.1 - частенько тоже. Навскидку - 3.0 был вообще труп трупом, третья ветка ожила только к 3.2; 4.0, 5.0, 7.0 - аналогично, изрядно нестабильные, и это только то, с чем лично сталкивался.

ЗЫ первый мой рабочий релиз был 2.2.5, на сервере - 3.2, за себя скажу - настраивается всё в FBSD понятно, система несложная и прозрачная насквозь. Магией страшных многомегабайтных конфигов и скриптов не испорченная. Для сравнения, другие рабочие ОС - ALT Linux 5 и Kubuntu (6.06 ... 11.10) - очень сложные, лично я не могу в них охватить, как в FreeBSD или RedHat Linux 4.0/6.0, всю систему загрузки/инициализации. Временами кажется, что Линукс усложняется ради усложнения только.

FreeBSD - это по сути такой же дистрибутив, как и куча дистрибутивов Linux, только на другом ядре. Говорят, что это ядро способно обрабатывать миллиарды сетевых запросов в секунду, что оно лучше рихтуется под работу с сетью Аналогичная есть история, например, о ядре AIX, которое после влючения асинхронного чего-то (уже забыл), становится сущим идеалом для работы СУБД Oracle. Но AIX язык не повернётся назвать только ядром: вокруг него - огромная уникальная инфраструктура, тесно завязанная на возможности IBM p-серии. FreeBSD же... ну ок, есть GEOM. Это всё, что можно так с ходу вспомнить. Из глубоких вещей - ещё ZFS «позаимствовали». Но только ZFS глупо было бы считать отличительным признаком FreeBSD как самостоятельной операционной системы, иначе можно прийти к тому, что наличие CIFS - отличительный признак Linux как разновидности ОС семейства Windows. И FreeBSD, и Linux - «основы» для сборки одного и того же конструктора, и то, что у FreeBSD дистрибутивов меньше, чем у Linux, ещё не делает ядро самостоятельной системой.

И да, стремление таскать за собой неуклюжие утилиты, дублирующие утилиты GNU, но делающие всё хуже, - это маразм проекта FreeBSD, как раз преследующий целью показать, что у них-же всё своё. А то, что все эти утилиты, вместе взятые, не потянут даже на 10-ю часть кода какой-нибудь Cairo - этот как бы вообще неважно.

А я не думаю, что FreeBSD дублирует утилиты GNU. В GNU/Linux есть предостаточно утилит позаимствованных от старой BSD UNIX.

Хотя во времена GCC 4.2 оптимизации под Intel Atom в компилятор ещё не внесли.

Документация gcc известна мне лучше, чем отче наш. Учитывал отсутствие параметра atom до версии 4.5, но не собиралось при '-O2 -march=native'. Ни в какую. Кстати, pipe при компиляции с оптимизацией ниже уровня -O3 в gcc только подтормаживает. При -O2 и ниже в большинстве случаев компилируется быстрее без этого параметра.

Вообще же, попробуй заменить компилятор на более свежий, скажем, на GCC 4.6.4 (порт lang/gcc46). Краткая инструкция по переходу на новый компилятор: http://www.freebsd.org/doc/ru/articles/custom-gcc/article.html Новый компилятор поддерживает куда больше возможностей по оптимизациям.

Насчет gcc-4.6.4 не пробовал, проверял вплоть до версии 4.6.2, но по сравнению с 4.5.3 все проверенные версии на атомах выдавали менее производительный код.

В /etc/make.conf впиши:

По поводу куда, что вставить я разобрался быстро - у Вас на bsd это намного легче, чем на linux, переписал под свое железо и make.conf и настройки ядра, модулей. Но.. компилировать отказывалось. По логам выявить причину не удалось, а разбираться более менее серьезно просто не хватило тогда времени.

P.S.

Из интересных наблюдений за период того тестирования - некоторые комбинации ключей вместе с -O1 выдавали лучший результат, чем с параметром -O2 на gentoo. Да и вообще сильно влияет порядок следования ключей. Иной раз случайно поменяв их местами, можно получить существенный прирост в производительности. Но отчего это происходит не могу сказать, так как не анализировал исходники gcc.

А что скажете насчет dragonflybsd? Пробовали?

Давно игрался с Dfly и пришел к выводу, что мне, лично, это не нужно.

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

P.S. Меня в dfly заинтриговал необычный подход с нитями ядер. С одной стороны вроде бы дополнительные накладные расходы, но ведь сколько примеров, когда более сложные алгоритмы позволяли увеличивать производительность. Хотелось бы более конкретно сравнить bsd системы со своей gentoo, чтобы уже определиться с направлением вектора приложения усилий. В дженте достали ненормальные ebuild - сколько можно уже отлавливать там огрехи? Ведь система gentoo не вчера родилась. Достала просто эта неразбериха с постоянной перекройкой ebuild.

Мой подход к ОС сугубо прагматичный. Поэтому добиваюсь прежде всего видимых, конкретных результатов. Я интересуюсь ОС ( в данном случае FreeBSD ) на уровне опытного пользователя/администратора.

Ты познал истинный смысл Дзен! ;-))))

Каким образом существование трупа может быть кому-либо невыносимо?

Да заткнись ты уже, труп. Сколько можно вонять одно и то же по сто раз.

Ничего не могу сказать. Не пробовал.

Без acpi у вас больше одного ядра не поднимется. Я имею в виду технологию а не название модуля.

FreeBSD - это по сути такой же дистрибутив, как и куча дистрибутивов Linux, только на другом ядре

отсыпь, шоле... :)

-g0 -O3 -march=atom -mtune=atom -mmmx -mssse3 -mfpmath=sse -fmerge-all-constants -fno-gcse -funroll-all-loops -fno-tree-pre -fno-tree-forwprop -fno-cprop-registers -fno-predictive-commoning -fno-inline-functions-called-once -funsafe-loop-optimizations -fno-tree-vectorize -fomit-frame-pointer -pipe

жесть какая. Расскажешь что флаги из себя представляют, что бы мне в man не лезть? :)

FreeBSD - это по сути такой же дистрибутив, как и куча дистрибутивов Linux, только на другом ядре

Windows - это по сути такой же дистрибутив, как и куча дистрибутивов Linux, только на другом ядре ... И да, стремление таскать за собой неуклюжие утилиты, дублирующие утилиты GNU, но делающие всё хуже, - это маразм проекта Windows, как раз преследующий целью показать, что у них-же всё своё. А то, что все эти утилиты, вместе взятые, не потянут даже на 10-ю часть кода какой-нибудь Cairo - этот как бы вообще неважно.

ЗЫ Киса, ты с какова горада?

PC-BSD 9.0

Эта скотинка добавляет НЁХ в /etc/pf.conf при каждой перезагрузке, что доводит меня до тихого бешенства. И с теми правилами по умолчанию, которые там приняты — ждите гостей (т.к. бэкдор).

отсыпь, шоле... :)

А чего отсыпать-то, если различий между Crux и Ubuntu на порядок больше, нежели между Crux и FreeBSD, а само ядро FreeBSD используется как «одно из возможных» в Debian. На 99,9% FreeBSD состоит из тех же приложений, что и любой дистрибутив Linux, а отличается какое-то унылое говно: например, реализация sed из проекта FreeBSD и маниакальное стремление таскать за собой (и впаривать пользователю насильно не мытьём, так катаньем) дебильную оболочку csh, протухшую сразу после рождения, систему портэжей, выносящую мозг компиляцией из исходников в т.ч. на системах, которые могли бы процессорную мощность куда полезнее расходовать. Ну и да, можете что угодно говорить, но для относительно «редкого» софта, в работе которого как правило и заключается цель существования всех этих чудесных *BSD и прочих *nix, я не раз, не два и не 10 сталкивался с тем, что установка из портэжей приводила к ошибкам make в лучшем случае, а в худшем случае - наносила каких-то непонятных хидеров в систему, из-за которых уже систематически ломалась установка портов.

На 99,9% FreeBSD состоит из тех же приложений, что и любой дистрибутив Linux

Чуть больше, чем GNU/Linux. Вернее, ровно настолько, насколько количество портированных программ на FreeBSD больше того количества, который содержит репозиторий конкретного дистрибутива. (И, да, засчитываются только программные продукты, а не пакетики, на которые они раздроблены тем или иным образом.)

реализация sed из проекта FreeBSD

Что-то не работает?

дебильную оболочку csh

Ты сейчас оскорбил создателя vi.

систему портэжей

Портежи — это на Gentoo. На FreeBSD есть чёткая и непротиворечивая коллекция портов, гарантирующая сборку и сопровождение установленных программных пакетов.

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

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

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

За 6 лет не встречалась такая ситуация. Программа компилируется и устанавливается, либо не компилируется и не устанавливается — третьего не дано, если сам специально не «помогаешь» и не делаешь из Unix-системы собственного клона GNU/Linux только на ядре FreeBSD.

реализация sed из проекта FreeBSD

sed -E пробовали? ;)

man sed

-E      Interpret regular expressions as extended (modern) regular
             expressions rather than basic regular expressions (BRE's).  The
             re_format(7) manual page fully describes both formats.
<...>
-r      Same as -E for compatibility with GNU sed.

Мне гораздо чаще нужен sed -i, а синтаксис sed -i.bak во FreeBSD ломает совместимость со скриптами, написанными в куда более распространённой ОС (я не про офтопик, да)

Ну так, а я о чём?) Да, про -r забыл, но собственно показать хотел всё тоже: Всё ок с BSD sed'ом.

Ты наверное не знаешь о утилитах базовой системы по управлению бинарными пакетами pkg_*

И много ими можно установить? Я уж не говорю о степени удобства: этим утилитам до apt-get'а как пешком из Урюпинска до Парижа.

Программа компилируется и устанавливается, либо не компилируется и не устанавливается

Я сталкивался со вторым типом ситуаций недостаточно редко для того, чтобы считать систему портов консистентной за рамками установки Pidgin или Apache. Но был и 3-й тип ситуаций: что-то компилировалось с кучей Warning'ов, как-то ставилось, а потом даже то, что раньше устанавливалось из портов, в друг начинало вываливаться на make.

man sed (в centos 5.7):

       -i[SUFFIX], --in-place[=SUFFIX]

              edit files in place (makes backup if extension supplied)

man sed (в FreeBSD 7.4):

     -I extension
             Edit files in-place, saving backups with the specified extension.
             If a zero-length extension is given, no backup will be saved.  It
             is not recommended to give a zero-length extension when in-place
             editing files, as you risk corruption or partial content in situ-
             ations where disk space is exhausted, etc.

             Note that in-place editing with -I still takes place in a single
             continuous line address space covering all files, although each
             file preserves its individuality instead of forming one output
             stream.  The line counter is never reset between files, address
             ranges can span file boundaries, and the ``$'' address matches
             only the last line of the last file.  (See Sed Addresses.)  That
             can lead to unexpected results in many cases of in-place editing,
             where using -i is desired.

     -i extension
             Edit files in-place similarly to -I, but treat each file indepen-
             dently from other files.  In particular, line numbers in each
             file start at 1, the ``$'' address matches the last line of the
             current file, and address ranges are limited to the current file.
             (See Sed Addresses.)  The net result is as though each file were
             edited by a separate sed instance.

Да, я понял о чём ты. То, что линуксе

sed -i -e 's/test/tset/g' test.txt

sed -I '' -e 's/test/tset/g' test.txt

Однако, не всё так уж и печально имхо:

1) Скрипты можно поправить (тем же sed'ом ;) )

2) Можно поставить из портов gsed.

И много ими можно установить?

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

этим утилитам до apt-get'а как пешком из Урюпинска до Парижа.

pkgng, portupgrade (portinstall -PP будет ставить всё из пакетов), portmaster (там тоже аналогичные ключи есть).

Я сталкивался со вторым типом ситуаций недостаточно редко для того, чтобы считать систему портов консистентной за рамками установки Pidgin или Apache. Но был и 3-й тип ситуаций: что-то компилировалось с кучей Warning'ов, как-то ставилось, а потом даже то, что раньше устанавливалось из портов, в друг начинало вываливаться на make.

Я практически не сталкивался с подобным. Разве что, если давно не обновлял порты, а дерево портов обновлял и устанавливал потом что-то. Лечилось обновлением портов =)

Ты наверное не знаешь о утилитах базовой системы по управлению бинарными пакетами pkg_*

И много ими можно установить?

Да практически 100% рабочий десктоп, если есть в наличии все необходимые бинарные пакеты (записанные на DVD, к примеру).

Лечилось обновлением портов =)

и внимательным чтением предупреждающих сообщений в /usr/ports/UPDATING. =)

Восьмёрка, была в этом плане конфетка, с семёркой проблем так же не было...

О том что в linux нету проблем: раскажешь девушкам.

О чём конкретно?

О том что портировали новый pf? О том что он толком не работает? Или о том что до сих пор не пофиксили?

http://www.freebsd.org/cgi/query-pr.cgi?pr=163208

Вообще pf, чем дальше тем хуже поддерживается. Количество незакрытых pr большое. Печалька, на ipfw переходить не хочется.

У меня PF работает.

Куда ж без этого)

Ясно. Возможно поэтому dragonflybsd проявил себя хуже.

Вышлa в свет FreeBSD

Поднимите мои веки..

Согласен жесть, но на атоме эти ключи работают.

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

Меня уже развратил PPA Launchpad, обожаю эту штуку не меньше, чем ненавижу Unity :) Вряд ли проект FreeBSD дойдёт до уровня удобства «add-apt-repository URL && apt-get update && apt-get install курительную_трубку мне_пожалуйста»

Да практически 100% рабочий десктоп, если есть в наличии все необходимые бинарные пакеты (записанные на DVD, к примеру).

Проблема в том, что pkg_add redmine не работает, а это, как сейчас говорят, «пичалька»...

Проблема в том, что pkg_add redmine не работает

redmine не нужен после того как его до сих пор на третьи рельсы не перевели