Debian объявляет об официальной поддержке kFreeBSD

>> Ок, так и запишем - ZFS больно бъет по яйцам процессора no-dashi, который, бедолага, настолько стар, что ему контрольные суммы для потока данных в 200 МБ/c посчитать невмоготу.

> А теперь расскажите это тем идиотам^Wсчастливым обладателям техники Sun, которые три года назад купили такие замечательные мегапроцессоры в свой мегасервер, которые (опа!) полностью загружаются по самые уши простой операцией записи или даже чтения (при чтении тоже просчитывается контрольная сумма, вы же клятвенно обещали коррекцию ошибок)

Циферки в студию. А то больно уж вы горазды на выдумки

> У ZFS много интересных фич, но эти фичи следовало бы разнести по разным уровням

Ну так давайте - разнесите. Напишите свой NDFS, который вберет в себя все ваши замечательные мысли насчет правильного разнесения функциональности по уровням. Чтобы строго все было, как в аптеке.

> - проверку целостности отдать в блочный устройства (внезапно, можно написать target для device-mapper который будет это делать, или отдать в умный контроллер класса smartarray), распределение пространства оставить volume manager'у, а журналирование отдать в FS.

Когда ждать?

И накой при таком подходе сдалась BTRFS, ответьте? Ведь она тоже неклассически реализует в себе функции менеджера томов, зачем-то считает контрольные суммы, и вообще стремиться быть похожей на ZFS. Ась?

> Но блин, получаеncz линуксовая архитектура :-)

LOL. Ржунимагу. Линуксовая архитектура! Че там отец-основатель недавно ляпнул насчет huge'n'bloated?

>> Вот только не надо, что у традиционных ФС требования к памяти и процессору никак не связаны с размером дискового пространства

> Связаны,

Как вы быстро, однако, от своих слов отказываетесь ;-)))

> но не так сильно, как это наблюдается у ZFS

А как сильно это наблюдается в ZFS? Сами измеряли? Или из передач Радио ОБС узнали?

> Когда пытаешься подключиться на любой TCP-порт, будь готов, что обратно может вернуться ICMP-сообщение Port Unreachable.

=) никогда в жизни такого не произойдет. если порт недоступен, вернется tcp reset. port unreachable используется только совместно с udp.

> Хинт - ZIL использует fletcher 2

Тот самый fletcher2, который возвращает одинаковый CRC для 1,1,1,1,1,1,1,1 и 1,2,1,0,1,0,1,2??? Дааа, хороший хэш, ничего не скажешь :-) Я же говорю главные задачи ZFS - дать возможность леммингам пошуметь в интернетах и навесить лапши менеджерам - выполнена на пять с плюсом.

>> в пф тоже. причем, пропускаются и менглятся все релейтед ицмп сообщения.

> Спасибо, хоть кто-то по делу ответил.

> А пруф можно?

pf.c? честно говоря, я не понимаю, как я должен привести пруф ))
если скажешь, что может служить пруфом, я конечно приведу

> Кстати, какие там есть средства выявления сканирования портов (os fingerprinting для nmap не предлагать)?
вроде как интегрированных средств нет. где-то видел что-то стороннее, но не уверен.

> А без вариантов, только оупен бгпд, из кваги так не получается. Этот "тандем" только для потому и выбран, что вот такую фичу в паре может. Хотя тут, конечно, сложно сказать, кто из них в этом плане молодец, а кто "плывет по течению", т.к. это в openbgpd и говоришь, например,
allow from any community 1111:2222 set pftable "tablename".. скорее.. это хорошая связка..

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

>> sv75, как ты оцениваешь сложность такой работы?

> Как выходящую за рамки %( Возможно, я ошибаюсь...

попробую напрячь кого-то из студентов, если им это будет интересно.

>> Ты правда считаешь разрабов ZFS такими тупыми?

> С чего бы вдруг?

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

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

А BTRFS тоже эту задачу решает? Архитектурно они схожи.

> Добавили контрольные суммы - ударили по яйцам процессору и дисковой подсистеме, увеличив количество записей в несколько раз.

Отключи хэши, если они стали узким местом.

Кстати, насчет СУБД... ты не из тех, кто любит держать БД на сырых разделах? :)

> Вводить контроль целостности для журнала и начинать все по новой? :-)

Поправь, если я ошибаюсь, но контроль целостности журнала есть уже в ext4.

P.S. я ни разу не фанат BSD и ZFS, но считаю очевидным то, что хотя бы метаданные ФС нужно прикрывать контрольными суммами.

> Кстати, насчет СУБД... ты не из тех, кто любит держать БД на сырых разделах? :)
Простите, а что в этом плохого?

>> Кстати, насчет СУБД... ты не из тех, кто любит держать БД на сырых разделах? :)

> Простите, а что в этом плохого?

Не знаю, я так не делал. А что в этом хорошего?

> Кстати, насчет СУБД... ты не из тех, кто любит держать БД на сырых разделах? :)

Я из тех, кто выбирает решения в зависимости от ситуации. Но собственно на дисковых разделах у меня баз нет - есть на разделах LVM на линуксе, и на ФС под виндой.

> Тот самый fletcher2, который возвращает одинаковый CRC для 1,1,1,1,1,1,1,1 и 1,2,1,0,1,0,1,2??? Дааа, хороший хэш, ничего не скажешь :-)

Во-первых, никто не утверждал, что fletcher2 - это криптографически сильная хэш-функция.

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

> Я же говорю главные задачи ZFS - дать возможность леммингам пошуметь в интернетах и навесить лапши менеджерам - выполнена на пять с плюсом.

Действительно, у леммингов появилась масса поводов шуметь о том, почему ZFS не нужна для линукса, но как только задается вопрос про BTRFS, эти же лемминги, в зависимости от постановки вопроса, либо уходят от него, как от чумы, либо забывают про все те технические причины, по которым они считают что ZFS не нужна в линукс, и начинают петь дифирамбы BTRFS и ждать, что ее "вот уже совсем скоро допилят" ;-)

Знаете как это назвается? NIH-синдром.

Можно подумать, если бы завтра ZFS появилась в линуксе, вы с упорством достойным лучшего применения, продолжали бы стоять на своем и не пользовались бы ею. Может и BTRFS не будете пользоваться по принципиальным соображениям, когда, наконец, ее "допилят"?

>pf.c? честно говоря, я не понимаю, как я должен привести пруф ))
>если скажешь, что может служить пруфом, я конечно приведу

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

> А что в этом хорошего?

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

Минусы - неудобно работать, надо вырабатывать определенные правила и методики, особенно если баз несколько. Впрочем, их (правила) все равно надо устанавливать, чтобы бардака не было - проверено на ФС.

> но как только задается вопрос про BTRFS

BTRFS - попытка повторить ZFS. Кому-то показалось это модным, большинству же (судя по скорости разработки) показалась более полезной ext4. Я уже приводил примеры - суперрешнеия выигрывающего по всем параметрам, просто не бывает. Либо это суперрешение будет для единичных клиентов :-)

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

> Отсутствие лишних кэширований, лишних записей (даже отложенных),

Это дает и O_DIRECT

> нулевая фрагментация,

Если создавать файл сразу нужного размера, у него тоже будет нулевая фрагментация.

> нулевой оверхэд, максимальная производительность - никто в принципе не обращается к устройству.

Это достигается размещением БД на выделенном устройстве.

> BTRFS - попытка повторить ZFS

А... тогда понятно.

> суперрешнеия выигрывающего по всем параметрам, просто не бывает. Либо это суперрешение будет для единичных клиентов :-)

С этим никто не спорит.

>возможно. просто кажется очевидным, что fully stateful packet filter таки полностью отрабатывает стейты

Таки полностью? :) А как насчет FTP, SIP, H.323 и т.п.?

> > Отсутствие лишних кэширований, лишних записей (даже отложенных),

> Это дает и O_DIRECT

atime, mtime - от их изменения как избавишься? А это все seek - самая хреновая (сильней всего влияющаяна производительность) из операций дисковых операций.

> Если создавать файл сразу нужного размера, у него тоже будет нулевая фрагментация.

Лишний уровень. LVM позволяет отрезать проивзольное количество нужных кусков и обеспечивает дополнительные функции - raid, on-line миграцию, снапшоты и прочее.

> Даже в гугль лезть не надо, чтобы увидеть, что от всех этих слова почему-то отдает запахом журналирования (через фонему Log), которое подразумевает двойную запись. Которое уже реализовано в СУБД, причем на порядок более эффективно.

Во-первых, циферки в студию про "на порядок больше".

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

> > > Отсутствие лишних кэширований, лишних записей (даже отложенных),

> > Это дает и O_DIRECT

> atime, mtime - от их изменения как избавишься? А это все seek - самая хреновая (сильней всего влияющаяна производительность) из операций дисковых операций.

Вот когда по делу говорите, никаких вопросов не возникает. А когда ерунду начинаете нести..

> > Если создавать файл сразу нужного размера, у него тоже будет нулевая фрагментация.

> Лишний уровень. LVM позволяет отрезать проивзольное количество нужных кусков и обеспечивает дополнительные функции - raid, on-line миграцию, снапшоты и прочее.

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

> > но как только задается вопрос про BTRFS

> BTRFS - попытка повторить ZFS.

Мы по-прежнему уходим от ответа. Будете стоять на своем и принципиально не использовать, потому что "комбайн-все-в-одном", или таки поступитесь принципами?

> Кому-то показалось это модным, большинству же (судя по скорости разработки) показалась более полезной ext4.

Чтобы написать хорошую файловую систему, требуется время. К тому же, если учесть, что ext4 не с чистого листа начиналась, то время ее разработки в несколько раз превосходит время разработки BTRFS, которая уже сегодня может больше, чем ext4.

> Я уже приводил примеры - суперрешнеия выигрывающего по всем параметрам, просто не бывает. Либо это суперрешение будет для единичных клиентов :-)

Цитату в студию - где было утверждение о том, что ZFS - это суперрешение, выигрывающее на всех задачах по всем параметрам?

Напоминаю вам, с чего начиналась дискуссия - со сравнения ZFS и связки LVM + любая линкусовая ФС. Поскольку по делу сказать было нечего, начались отползания в сторону баз данных, LVM по себе. и т.п.

А про суперрешение - это вы сами себе выдумали.

Ну не совсем 8-)

хороший пример вот в этой статье - при внешней схожести внутри большие отличия - как сумчатых животных от плацентных 8-)

http://www.networkattacheddatastorage.com/2009/07/31/btrfs-comparison-vszfs/

Кстати никто так и не рассказал - какой же у zfs дефрагментатор (хочетс ячто б он онлайновый был 8-))

для ZMC

> Объясняю как будто тебе шесть лет. Представь что у тебя канал на 5mbps, объем входящего трафика ты ни каким шейпером не ограничешь, сколько из вне пришло, столько пришло. Закинули из вне 5mbps пакетов, так закинули.

Та что ж ты будешь делать... То, о чем Вы, zmc, говорите, действительно так и будет, но только для UDP, ну и еще при ситуации, когда какой-то умник решит побаловаться командой "ping -f". А вот для TCP история будет ДРУГАЯ!!! Там же есть понятие ОКНА, ну епт, ну как еще обьяснить? Короче, мля, лучше больше не говорить...

> А щас внимание сюрприз - до твоего шейпера они все равно дойдут тока после того как все это барахло примет сетевая, то есть забьет свой канал на еденицу времени.

Да да и да! дойдут! только если это УДП, ну или ping -f как говорилось на пару строк выше, или броад/мультикаст какой-то, или ХЗ что- из Layer2...

А вот если TCP? будет слать удаленный хост еще данные через 5мбит канал, если еще не получен ответ с контрольной суммой? будет? По крайней мере до окончания таймаута даже и не попытается. А это все потому, что мы на нашем шейпере просто пакеты НЕ пропустили, и прямо с инпута загнали их в очередь "согласно купленным билетам"(я имею в виду то, что идентификатор транЗакции у всех пакетов из одного тсп-окна один), а мы делаем именно shape, а не rate-limit, и все пакеты аккуратненько попадают в точку назначения, на хост, который уже в нашей сети, только вот попадают с задержкой. Ответ, таким образом, также задерживается. А ЗНАЧИТ СЛЕДУЮЩЕЕ ТСП-ОКНО ПРИДЕТ К НАМ ПОЗЖЕ. И вуаля, мы ограничили входящую скорость!

> Если и щас не дойдет, то наверное с вами мне действительно дальше говорить не о чем.

Уважаемый zmc, если вы до сих пор уверены в своей правоте, то блин задумайтесь! Каким же образом осуществляется шейп скорости даунлоада для клиентов (коротые шейпером и обслуживаются), если все происходит настолько трагически, как говорите вы? Или вы хотите сказать, что если аплинка 10 мбит, подключен клиент на 100 мбит(физически, витой парой), но скорость пошейплена в 5, то когда он начнет свою долбанную закачку, то он и получит своих долбанных 5, а остальные 5 просто засрутся тем, что будет пытаться впарить вашему клиенту удаленный хост? И больше никто ничего на этом аплинке не получит? Да это ж даже ... не смешно...

P.S. Хотя я думаю, что понял , что имеете в виду Вы. Вы хотите сказать, что нельзя внести задержку при получении, но можно это сделать при отправке. Совершенно верно. Но я ведь говорю о перемещении пакета в очередь! Если вы для себя ответите (для меня не нужно), в каком тайном месте всей системы она (очередь) вообще находится, то и вы поймете то, о чем говорил я.

> atime, mtime - от их изменения как избавишься?

Думаю, с atime всё понятно?

> А это все seek - самая хреновая (сильней всего влияющаяна производительность) из операций дисковых операций.

На разделе лежит десяток-другой очень больших файлов для dataspace'ов, и ты правда думаешь, что запись mtime для них на что-то повлияет?

Повлияет если метаданные (atime,mtime) лежат далеко от данных. seek у нас большой. 8-/

> Повлияет если метаданные (atime,mtime) лежат далеко от данных. seek у нас большой. 8-/

Забудь про atime. А seek вообще неизбежен.

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

я вот думаю над вашими словами о множественных таблицах маршрутизации... вы сейчас имеете в виду multiple fibs, которые вот во фре 7.2 и 6.4 одновременно появились? Только я вот.... не совсем понял... Это вообще возможно?? Я думал приблуда setfib запустит приложение (которым будет файрвол) в пределах одного фиба, как же оно сможет ориентироваться на остальные?

val-amart, а вы говорите о том, что pf понимает по какому fibу сейчас пролетает пакет? Хотя......... сетевки то.... одни и те же.... захват-то.. как то делить нужно.. какой бы фиб не был... Это просто мега интересно.... Благодарю за подсказку...

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

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

Единственное, чем РЕАЛЬНО недоволен - это тем, что хендлинг ошибок очень слабый... чуть что - сразу "emergency и exit 100 ".

Реальный пример для bgpd: После настройки сервака, через пару месяцев отменной работы, на площадке пропали 220. потом появились, ну, и начался стартап. В конфе bgpd есть строчка, которую я приводил выше, allow from any community 1111:2222 set pftable "tablename". По умолчанию, согласно порядку запуска rc скриптов, bgpd запускается раньше pf. Видит, что такого тейбла нету (а откуда ж ему взяться, если еще и pf не запущен), говорит, что "нет такого тейбла", и вылетает... Нет чтоб поднять пиров, проапдейтить маршруты системы, и работать себе, время от времени проверяя, не появился ли тейбл pf чтоб туда залить то, что нужно.. Это-то легко пофиксить, просто поменять порядок стартапа... Но вот она ошибка.

Пример для ospfd точно не вспомню, но приблизительно так: сообщает в лог, что "событие такое-то не ожидается на этапе EXCH", после чего вылет в нирвану. и это при взаимодействии как с кваггой, так и с хардварными пирами (типа 3com), но НИКОГДА - при взаимодействии с другим openospfd.

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

Никак не пойму, ЗАЧЕМ делать креш всего приложения, если ошибка влолне толково описывается в логе, а значит, возможность её появления ОЖИДАЕМА..

P.S. Но вообще - все это очень хорошие и нужные вещи. И pf, и bgpd, и ospfd (уж тихонько умолчим, что реально полезных уопенов - несчетное множество, и совсем даже не вспомним про тот же банальный sshd))))

> Кстати никто так и не рассказал

Дык вроде никто пока и не спрашивал :-)

> какой же у zfs дефрагментатор (хочетс ячто б он онлайновый был 8-))

Пока никакого, но работы в этом направлении ведутся. Когда сделают - естественно будет онлайновый.

> > Повлияет если метаданные (atime,mtime) лежат далеко от данных. seek у нас большой. 8-/

> Забудь про atime. А seek вообще неизбежен.

Большой или нет, неизбежен или нет - зависит от того, какая файловая система, какой характер нагрузки.

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

Если ФС использует COW, то все эти случайные операции записи, включая обновление mtime, превращаются в одну большую последовательную операцию записи, так что seek может быть и не нужен.

> > Кстати никто так и не рассказал

> Дык вроде никто пока и не спрашивал :-)

iZEN кричал что "ext4 сакс" так как обещали но не сделали дефргаментатор 8-)

>> какой же у zfs дефрагментатор (хочетс ячто б он онлайновый был 8-))

> Пока никакого, но работы в этом направлении ведутся. Когда сделают - естественно будет онлайновый.

дык - везде ведутся, не только в zfs/ufs и т.д.

> iZEN кричал что "ext4 сакс" так как обещали но не сделали дефргаментатор 8-)

это весьма сложно воспринять как вопрос о том, какой дефрагментатор у ZFS.

А если спросить прямо - то и ответить не проблема. Прятать-то нечего, код открыт ;-)

>> возможно. просто кажется очевидным, что fully stateful packet filter таки полностью отрабатывает стейты

> Таки полностью? :) А как насчет FTP, SIP, H.323 и т.п.?

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

> я вот думаю над вашими словами о множественных таблицах маршрутизации... вы сейчас имеете в виду multiple fibs, которые вот во фре 7.2 и 6.4 одновременно появились? Только я вот.... не совсем понял... Это вообще возможно?? Я думал приблуда setfib запустит приложение (которым будет файрвол) в пределах одного фиба, как же оно сможет ориентироваться на остальные?

> val-amart, а вы говорите о том, что pf понимает по какому fibу сейчас пролетает пакет? Хотя......... сетевки то.... одни и те же.... захват-то.. как то делить нужно.. какой бы фиб не был... Это просто мега интересно.... Благодарю за подсказку...

хм. немного самопиара ж). посмотрите мое видео и слайды тут: http://uaoug.org.ua/openkyiv/2009/materials/ (доклад о динамической маршрутизации)
надеюсь, картина прояснится, если нет, то задавайте ваши вопросы, с удовольствием отвечу.

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

> По умолчанию, согласно порядку запуска rc скриптов, bgpd запускается раньше pf. Видит, что такого тейбла нету (а откуда ж ему взяться, если еще и pf не запущен), говорит, что "нет такого тейбла", и вылетает... Нет чтоб поднять пиров, проапдейтить маршруты системы, и работать себе, время от времени проверяя, не появился ли тейбл pf чтоб туда залить то, что нужно.. Это-то легко пофиксить, просто поменять порядок стартапа... Но вот она ошибка.

это реальная ошибка, спасибо за репорт. кстати, вы не пробовали репортить баги и даже просто предложения в миск@ или bugs@openbsd.org? я гляну скоро или это еще не пофиксили.

> Пример для ospfd точно не вспомню, но приблизительно так: сообщает в лог, что "событие такое-то не ожидается на этапе EXCH", после чего вылет в нирвану. и это при взаимодействии как с кваггой, так и с хардварными пирами (типа 3com), но НИКОГДА - при взаимодействии с другим openospfd.

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

вообщем, будем рады видеть ваши багрепорты.

>atime, mtime - от их изменения как избавишься?

Этими свойства файловой системы можно управлять (например, отключить их).

Кстати никто так и не рассказал - какой же у zfs дефрагментатор (хочетс ячто б он онлайновый был 8-))

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

http://blogs.sun.com/bonwick/ru/category/ZFS

В целом стек преобразований в ZFS выглядит так:

ZPL: имя файла - объект DMU: объект - DVA (data virtual address) SPA: DVA - LBA диска

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

>просто напрягать файрволл парсингом всего и вся - это создавать очередной мс форефронт секьюрити.

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

Помнится, полгодика назад мы с товарищем true_admin дискутировали на тему «должно ли ядро выполнять функции IDS/IPS?» Сошлись на том, что если оно эти функции исполняет _хорошо_, то конечно должно. И в том же линухе есть вполне неплохие наработки: fwsnort (система поиска вредоносных сигнатур), psd и lscan (системы обнаружения сканирования портов), ну а по части борьбы с ддосом функционал примерно такой же, как и у pf.
Подобные решения обычно выигрывают как по простоте развертывания, так и по производительности.

С fully stateful packet filter ситуация аналогичная. Проще написать modprobe nf_nat_ftp, чем поднимать FTP-прокси и полдня прыгать вокруг него и фаервола с бубном, обеспечивая нормальную работу активного и пассивного режима.
А на FTP-сервере — тоже прокси ставить? Или открывать почти треть портов всем ветрам?

В общем, лично меня очень расстраивает варварское ограничение функций pf четвертым уровнем.

Кстати, вопрос по ассоциации: как у pf с возможностями bridge firewall?

>Пока никакого, но работы в этом направлении ведутся.

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

Кстати, вопрос по ассоциации: как у pf с возможностями bridge firewall?

http://www.opennet.ru/base/sec/pf_openbsd_altq.txt.html

ext_if = xl0
int_if = xl1
interesting-traffic = { ... }
block all
pass quick on $ext_if all
pass log on $int_if from $int_if to any port $interesting-traffic

как отключить mtime? можно пример команды для zfs?

ну вот народ уверен в обратном 8-) http://lwn.net/Articles/342892 в частности valeri aurora, которая работала в сан в группе по разработке zfs

...

In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS. One of the major problems with the ZFS approach - "slabs" of blocks of a particular size - is fragmentation.

...

>> Пока никакого, но работы в этом направлении ведутся.
> Не слышал криков по поводу необходимости в дефрагментации ZFS (и UFS2, кстати тоже).

Я может чего не догоняю, благородные доны, но ZFS - copy on write. Какой там смысл в дефрагментации если данные не планируется делать readonly? :)

Вообще, забавно читать споры тех кто использует ZFS с теми кто ее никогда не использовал :)

> ну вот народ уверен в обратном 8-) http://lwn.net/Articles/342892 в частности valeri aurora, которая работала в сан в группе по разработке zfs

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

Так что читайте исходники - они рулез!

>> просто напрягать файрволл парсингом всего и вся - это создавать очередной мс форефронт секьюрити.

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

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


> Помнится, полгодика назад мы с товарищем true_admin дискутировали на тему «должно ли ядро выполнять функции IDS/IPS?» Сошлись на том, что если оно эти функции исполняет _хорошо_, то конечно должно.

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

> С fully stateful packet filter ситуация аналогичная. Проще написать modprobe nf_nat_ftp, чем поднимать FTP-прокси и полдня прыгать вокруг него и фаервола с бубном, обеспечивая нормальную работу активного и пассивного режима.

в pf.conf:
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
anchor "ftp-proxy/*"

и в rc.conf.local:
ftpproxy_flags=""

сложно? неособо, все строчки скопированы с фака. конечно, твой вариант проще. мой - правильнее, имхо.

> А на FTP-сервере — тоже прокси ставить? Или открывать почти треть портов всем ветрам?
всмысле? ты имеешт ввиду если пф на фтп сервере?

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

> Кстати, вопрос по ассоциации: как у pf с возможностями bridge firewall?
легко и не принужденно. просто насраиваешь мост и фильтруешь на его интерфейсах.

> Я может чего не догоняю, благородные доны, но ZFS - copy on write. Какой там смысл в дефрагментации если данные не планируется делать readonly? :)

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

> Вообще, забавно читать споры тех кто использует ZFS с теми кто ее никогда не использовал :)

Причем те, кто не используют, продолжают упорно уходить от прямого вопроса - будут ли они использовать ZFS (если она вдруг появится в линкусе) или BTRFS (когда ее уже "совсем скоро допилят"), или будут продолжать героически стоять на своем и не пользоваться, потому что "комбайн-все-в-одном".

Что-то мне подсказывает, что будут ;-)

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

>кстати, как они в сравнении с тем же снортом (никогда не пробовал)?

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

>сложно? неособо, все строчки скопированы с фака. конечно, твой вариант проще. мой - правильнее, имхо.

Как я понял, ftp-proxy парсит трафик и по мере необходимости добавляет нужные правила в pf. Честно говоря, по сравнению с conntrack, который просто выставляет связанным соединениям _стейты_, производит некоторое впечатление костыльности. Ну ладно.

А для SIP, IRC, H.323 тоже подобные штуки есть?

>всмысле? ты имеешт ввиду если пф на фтп сервере?

Ага. И пассивный режим.

>легко и не принужденно. просто насраиваешь мост и фильтруешь на его интерфейсах.

Это хорошо.