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

>Если разрешить только TCP подключение на 80 порт, будут ли обратно пропускаться ассоциированные с ним ICMP-пакеты?

Если разрешишь — будут.

>А если разрешить TCP-подключения на 21 порт, будут ли пропускаться соединения для передачи данных?

Какие соединения? По 21 порту — будут пропускаться только TCP-пакеты на порт 21. Похоже ты не различаешь порты TCP и других протоколов.

>А если разрешить подключение на 1723 порт TCP, будет ли разрешено прохождение GRE-пакетов для подключившихся клиентов?

Что за бред? Ты всегда в одну кучу сваливаешь порты разных протоколов?





Просветись: http://rootfox.com/BSDA-course/apcs02.html
И здесь тоже почитай (на всякий случай): http://fiery-fenix.kiev.ua/archives/17-FreeBSD_i_GRE._Proksirovanie_na_odin_V...

>можно с этого места поподробнее?

Где-то тут обсуждали с реальными примерами: http://www.linux.org.ru/view-message.jsp?msgid=3262617&page=-1

Вот же прямая ссылка: http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3272939

Ещё: http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3274139

>Что за бред? Ты всегда в одну кучу сваливаешь порты разных протоколов?

Ты дурак или прикидываешься?

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

У FTP два соединения - одно управляющее, другое для данных. Если тебе заранее не известно, каким образом FTP-клиент и FTP-сервер решат соединиться для передачи данных, какое разрешающее правило ты добавишь? Ты будешь точно знать только их IP, но не будешь знать кто из них инициирует соединение и какие TCP-порты они для этого используют.

На 1723 порту TCP работает PPTP-сервер. Да будет тебе известно, что протокол PPTP использует два протокола - TCP и GRE. Каким образом ты разрешишь прохождение GRE-пакетов только тем, кто установил TCP-подключение?

>в зфс собственно фс и менеджер томов - единое целое

Несовсем. В zpool'е можно создать UFS2.

>Просветись: http://rootfox.com/BSDA-course/apcs02.html

http://www.opennet.ru/docs/RUS/iptables/

И что?

>И здесь тоже почитай (на всякий случай): http://fiery-fenix.kiev.ua/archives/17-FreeBSD_i_GRE._Proksirovanie_na_odin_V.. .

Что я вижу?

>Для начала опишу конфиг - FreeBSD 6.2-RELEASE-p3 + pf фаервол. Прикол заключается в том что pf не умеет натить GRE с нескольких локальных машин на один (!) внешний VPN сервер. Обидно. Ладно, где наша не пропадала.

iptables умеет натить PPTP, а где же ваша не пропадала рассказывай другим.

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

Если не знаешь броду - не лезь в воду. Объясняю в двух словах: в конфигах можно смотреть содержимое таблиц (если они статические), а также названия интерфейсов и очередей. Т.Е. посмотреть саму конфу. В выводе pftop - смотреть ЧТО по какому правилу проходит, и в какую очередь попадает, с конкретными названиями и цифрами каунтеров. Т.Е. увидеть КАК РЕАЛЬНО КОНФИГ РАБОТАЕТ. А приводилось это только для того, чтоб подтвердить факт, что шейпать траф можно классифицируя его только на инпуте интерфейса. Проще говоря - что нужно написать,и как это будет работать.

>>P.S. а если ты имеешь в виду не ситуацию в целом, а какую-то ее конкретную часть (именно средства фаерного шейпера), то имей сколько угодно, в том же сообщении(или предыдущем), часть которого ты выделил, были указаны все имеющиеся в виду механизмы шейпа... > Да, что ты говоришь. Перечитай еще раз свой пост, или ты как та собака все понимает, но (правильно)сказать не может. Во первых, ты же не думаешь, что я буду вот все перечитывать, для того, чтоб просто найти нужное сообщение? А во вторых, говорю тебе, что было, притом где-то в таком виде (для pf - altq, а для ipfw - netgraph, dummynet или родные pipes).

Спора про шейперы, как такового, и не было вовсе, мы тут пытались просто (грубо говоря) понять, какие можно из общей ситуации получить выгоды. А вы, дорогой друг, вы применяете несколько неприНятные для цивилизованного общества слова. Посему дальнейшее обсуждение считаю нецелесообразным.

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

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

А пруф можно?

>в pf это тоже есть ;)

А то я про overload не знаю :)

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

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

Вы лучше для начала скажите, контроль целостности в ZFS включен на уровен пула, или на уровне файла? :-)

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

Тебя Иптаблес научило задавать такие дурацкие вопросы?

>У FTP два соединения - одно управляющее, другое для данных...

Ты меня специально подлавливаешь на том, что написано в PF.FAQ или сам дурак?

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

>Тебя Иптаблес научило задавать такие дурацкие вопросы?

Меня научило знание стека TCP/IP, это только ты учишься владению инструментами, не зная теории.

>Ты меня специально подлавливаешь на том, что написано в PF.FAQ

Молодец, ты даже PF.FAQ прочитал. Оказывается, для того чтобы узнать как работает FTP, нужно прочитать FAQ?

>или сам дурак?

Это было последней каплей. Дурак здесь ты и это известно многим, даже местным вменяемым BSD'шникам вроде val-amart. До сих пор мне было интересно потешаться над тобой, но над больными смеяться нельзя. Отныне я отправляю тебя в игнор.

Вы лучше для начала скажите, контроль целостности в ZFS включен на уровен пула, или на уровне файла? :-)

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

Блоки пула дисковой памяти ZFS образуют дерево Меркле, в котором каждый блок проверяет всех своих «детей». Было доказано, что дерево Меркле обеспечивает криптографически стойкую аутнтификацию как для каждого компонента дерева, так и для всего дерева целиком. ZFS использует 256-битную контрольную сумму (алгоритм SHA-256) для каждого блока (метаданных) и проддерживает алгоритмы вычисления контрольных сумм для пользовательских данных начиная с простого и быстрого алгоритма fletcher2 (используемого по умолчанию) до медленного, но безопасного SHA-256. При использовании для пользовательских данных криптографически стойкого хеша, такого как SHA-256, контрольная сумма убер-блока является постоянно обновляющимся крипто-хэшем для всех данных в пуле.

А это будет очень удобно, если вам потребуется обратиться в UPS для пересылки пула.

для val-amart


> кстати, а что за бгп у вас? квагга? или опенбгпд?

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

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

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

> а pf что, не умеет по-твоему?
Это я вообще, привел лишь к тому, чтоб каким-то образом усилить эффект сказанного:) можно было вообще сказать, что "чуть ли не в зависимости от того, сколько раз за день оператор нажал клавишу ентер".
Если пример получился неудачный (ну, уже как бы и видно, что неудачный) то перефразируем именно так, пусть будет "ентер"))

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

na urovne blocka ili sektora :-)

>Меня научило знание стека TCP/IP, это только ты учишься владению инструментами, не зная теории.

Предпочитаю получать знания, изучая теорию И применяя её на практике.
А инструменты и есть связующее звено между теорией и практикой, никак иначе.

>Молодец, ты даже PF.FAQ прочитал. Оказывается, для того чтобы узнать как работает FTP, нужно прочитать FAQ?

Как работает FTP я знаю. А ты, похоже, не слушаешь ответы и продолжешь подковыриваться.

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

Фигасебе крохи! При изменении ОДНОГО блока данных ZFS пересчитывает хэши не менее ТРЕХ блоков:
1. самого изменившегося блока
2. блока который ссылается на изменившийся блок (по одному разу для каждого уровня дерева)
3. контрольную сумму в самом суперблоке

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

А теперь смотрим чуть выше :-)

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

И что? Если СУБД сама поддерживает целостность данных, заставлять ФС делать это ещё раз — непозволительная роскошь (иногда).

Поэтому идём в man zfs и что же мы видим:

The following native properties can be used to change the behavior of a
ZFS dataset.
...
checksum=on | off | fletcher2, | fletcher4 | sha256

Controls the checksum used to verify data  integrity.  The  default
value is "on", which automatically selects an appropriate algorithm
(currently, fletcher4, but this may change in future releases). The
value  "off"  disables  integrity  checking on user data. Disabling
checksums is NOT a recommended practice.

> Когда у меня льется 200 мегабайт в секунду блоками по 4 килобайта (СУБД!), это будет катастрофой

нет же, zfs не будет записывать и пересчитывать после каждого блока

> Если СУБД сама поддерживает целостность данных

СУБД полагается на операционку в вопросах обеспечения корректности сохранения данных и операция ввода-вывода.

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

Ну, теперь понятно почему ZFS такая жручая - требования к памяти и процессору растут пропорционально с объемом стораджа, в отличие от традиционных ФС.

> нет же, zfs не будет записывать и пересчитывать после каждого блока

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

>> нет же, zfs не будет записывать и пересчитывать после каждого блока

> Да ну? Контрольная сумма должна быть пересчитана после завершения операции записи

, которая будет отложена, а не будет производиться после каждого блока

Гыг, холивар. :)

> Сначала c00l][аKeP ставит убунту.... > Затем он трезвонит всем про то, как он крут и у него линукс... > Потом он ниасиливает убунту... Поверьте мне, убунту я асилил. И асиливал *NIX-системы еще тогда, когда это было ГОРАЗДО сложнее, чем сейчас.

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

> Но чтобы его не зачморили другие кулхацкоры... >Он ставит фряху и начинает говорить что "фряхя лучший севрер, винда > лучший десктоп, и каждому свое"... Именно - каждому свое. За исключением того, что фряха - не лучший сервер, она лучше в качестве гейта/фаервола/шейпера. Теперь из-за ZFS может стать лучше в качестве NAS (но это подождем 8-ку, где оно будет реализовано не в experimental). В некоторых других делах - например стандартный L(F)AMP веб-сервер она не хуже и не лучше линуха. Но ставить на фрю, например, оракл я не буду - ибо костыли. Как не буду предлагать линукс или фрю в качестве Enterprise-решения для предприятия на тысячи рабочих мест (кроме, возможно, некоторых частей сети), ибо просто TCO зашкалит.

> И это все в то время, когда линуксоиды спокойно работают в линуксе на десктопе с линуксоами на серверах :-)

А в это время большие компании, которые имеют большие деньги и умеют их считать, спокойно имеют леса AD-доменов на виндах, потому что пока более-менее доведенного до ума аналога AD, настолько же простого в управлении сетями от 10 до десятков-сотен тысяч хостов нет, базы данных с ораклами на линухах или солярах, шлюзы-днсы-вебсерверы на бсдях или линухах, рабочие станции на виндах, а кое-где на маках (на BSD-ядре, кстати). И все потому, что придумывать костыли, ограничивая свой выбор одной только ОС - это а) глупо, б) дорого.

>Фигасебе крохи! При изменении ОДНОГО блока данных ZFS пересчитывает хэши не менее ТРЕХ блоков: >1. самого изменившегося блока >2. блока который ссылается на изменившийся блок (по одному разу для >каждого уровня дерева) >3. контрольную сумму в самом суперблоке

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

> Когда у меня льется 200 мегабайт в секунду блоками по 4 килобайта (СУБД!), это будет катастрофой.

Это будет катастрофой для процессора пяти-десяти давности. Современные процессоры на одном ядре в один поток могут считать простые контрольные суммы типа флетчера со скоростью на порядок выше. А при моде на многоядерность/многопотоковость останется ещще куча циклов для всего остального.

> Ой, боюсь-боюсь! Вы конечно можете привести массу примеров того, как были выпущены миллионные тиражи попорченных дисков, причиной которых был не замеченный сбой на жёстком диске в процессе компиляции. А тут пришла ZFS и все проблемы сразу исчезли.

Проблемы не исчезли - они стали выявляться.

> А что, сейчас от этого кто-нибудь застрахован? Гораздо выше вероятность, что кто-то похакает почтовый сервер и отправит нужное ему письмо с поддельными заголовками и телом письма. См. мой ответ выше, начиная со слов "Ой, боюсь-боюсь!"

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

> Я вас понял, но не нужно переоценивать важность контроля целостности. Это неуловимый Джо, которого никто не видел, и который нафиг никому не сдался.

Я вас понял - вам целостность данных не важна. Ну так у вас все еще впереди. Флаг в руки.

ЗЫ. Вы только мне вот скажите, а то, что BTRFS собирается эту самую целостность контролировать - вас не смущает? Она ведь не нужна, зачем на нее время тратить?

понюхал http://wiki.debian.org/Debian_GNU/kFreeBSD_why и что то не понял
> In fact, we have removed some non-free binary-only drivers that are contained in the upstream FreeBSD tree, like the ath driver.

вроде ath полностью свободен уже?

>>в зфс собственно фс и менеджер томов - единое целое

Как таковых понятий ФС и менеджера томов в их традиционном понимании в ZFS нет. Это интегрированная система. Здесь подробнее:

http://blogs.sun.com/bonwick/ru/entry/rampant_layering_violation_russian

>Несовсем. В zpool'е можно создать UFS2.

Ну не в zpool'е, а на эмулированном томе. И не только UFS2, а и любую другую из имеющихся.

>Если не знаешь броду - не лезь в воду. Объясняю в двух словах: в конфигах можно смотреть содержимое таблиц (если они статические), а также названия интерфейсов и очередей. Т.Е. посмотреть саму конфу. В выводе pftop - смотреть ЧТО по какому правилу проходит, и в какую очередь попадает, с конкретными названиями и цифрами каунтеров. Т.Е. увидеть КАК РЕАЛЬНО КОНФИГ РАБОТАЕТ. А приводилось это только для того, чтоб подтвердить факт, что шейпать траф можно классифицируя его только на инпуте интерфейса. Проще говоря - что нужно написать,и как это будет работать.

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

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

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

> которая будет отложена, а не будет производиться после каждого блока

Вылазьте из така - это СУБД. Клиент (банкомат) заказал транзакцию. СУБД ее провела, операционка получила вызов write. Если запись не будет write станет отложенным, то СУБД посчитает что запись прошла и отошлет ответ банкомату, после чего тот выдаст деньги. В этот момент сервер встает колом в каком-нибудь кернел панике, и все отложенные записи потеряны. База при старте откатывается в последнее консистентное состояние (до начала транзакции).Списание со счета клиента не произошло, а денежки уже выданы!

Я всегда знал что солнцепоклонники, то есть виндузятники, то есть фрибздишники [ну в общем вы поняли кого я имел ввиду] весьма недалеки, но не думал, что у них ТАКИЕ проблемы с подготовкой по профильным дисциплинам :-)

> Это будет катастрофой для процессора пяти-десяти давности.

Ты похоже не понял - это СУБД. И либо подложка базы (операционка) выполняет каждую запись, и выход из { write;sync; } означает завершение записи с физическим помещением данных на диск, либо эта подложка идет в лес. Когда запись может быть отложенной, а когда нет, может решать только СУБД - только тогда выполняется основное требование "завершенный commit никуда не исчезнет".

> либо подложка базы (операционка) выполняет каждую запись, и выход из { write;sync; } означает завершение записи с физическим помещением данных на диск, либо эта подложка идет в лес

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

> Ты похоже не понял - это СУБД. И либо подложка базы (операционка) выполняет каждую запись, и выход из { write;sync; } означает завершение записи с физическим помещением данных на диск, либо эта подложка идет в лес. Когда запись может быть отложенной, а когда нет, может решать только СУБД - только тогда выполняется основное требование "завершенный commit никуда не исчезнет".

Сударь, кто тут что не понял - дак это ВЫ. Что такое ZIL рассказать? Или смоатоятельно в гугле найдете? А также что такое LogZilla?

> Я всегда знал что солнцепоклонники, то есть виндузятники, то есть фрибздишники [ну в общем вы поняли кого я имел ввиду] весьма недалеки, но не думал, что у них ТАКИЕ проблемы с подготовкой по профильным дисциплинам :-)

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

>Клиент (банкомат) заказал транзакцию. СУБД ее провела, операционка получила вызов write. Если запись не будет write станет отложенным, то СУБД посчитает что запись прошла

То есть ты считаешь, что если СУБД подтверждает транзакцию тогда, когда вернулось управление из системного вызова write(), то больше никаких проверочных действий со стороны сервера баз данных не проводится? То есть СУБД целиком и полностью полагается на "подложку" в вопросе сохранения собственных данных, собственной целостности и не использует даже "барьеры записи"? Прям удивил!

А я думал, что линупсоеды более просвещены в этих вопросах, ведь столько головняков поимели с md-raid и LVM и тут на тебе: Oracle (или PosgreSQL, или Firebird, не говоря уже о недо-транзакционном MySQL) проводит транзакцию на осыпавшемся винте и не видит никаких проблем?! Да, такое в пионер-линуксах возможно только, а не в продакшене. :)))

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

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

> То есть ты считаешь, что если СУБД подтверждает транзакцию тогда, когда вернулось управление из системного вызова write(), то больше никаких проверочных действий со стороны сервера баз данных не проводится?

Дружочек, я тебе по секрету скажу - у нас несколько десятков инсталяций оракловых серваков. И лично рекаверил ораклячьи и мускуловские базы, рассыпавшиеся из-за невовремя прилетевшего сбоя на слишком умных ФС с отложенной записью. Так что могу сказать - да, после возврата из write() СУБД считает, что данные записаны. Защитные механизмы есть, но они также предполагают, что после { write(); flush(); } данные уже на диске.

Почитайте что-либо кроме man zfs :-) Ну например документацию по Oracel ASM, али Informix Dynamic Server, или руководства по курсам performance tuning для СУБД, будете очень удивлены.

> Что такое ZIL рассказать? Или смоатоятельно в гугле найдете? А также что такое LogZilla?

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

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

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

Добавили контрольные суммы - ударили по яйцам процессору и дисковой подсистеме, увеличив количество записей в несколько раз.
Уменьшили количество записей путем объединения операций - потеряли в надежности (появляется очередь, кэш)
Ввели журнал - обавили точку отказа (что будет если данные будут искажены в журнале?)
Вводить контроль целостности для журнала и начинать все по новой? :-)

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

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

Помнится, вы неоднократно кичились тут, какие крутые интеловские процессоры рвут на британский флаг все остальные. А тут вдруг им флетчер со скоростью 200МБ/c непосильной задачей оказался.

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

> и дисковой подсистеме, увеличив количество записей в несколько раз.

Аргументируем. Что такое агрегация слышали? Сжатие? Не фиксированный размер блока? Потоковая запись?

> Уменьшили количество записей путем объединения операций

О, про агрегацию сылшали... Хорошо ;-)

> - потеряли в надежности (появляется очередь, кэш)

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

> Ввели журнал - обавили точку отказа (что будет если данные будут искажены в журнале?)

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

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

Все-таки хотя бы для общего развития и для того, чтобы не садиться в лужу раз за разом - почитайте что-нибудь, кроме постов на ЛОРе. Глядишь, что-нибудь полезное бы для себя почерпнули. Если получится.

Контроль целостности есть и для ZIL'а тоже.

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

А здесь вы забыли добавить IMHO. А о том, какую задачу они решали - лучше послушать их самих:

http://research.sun.com/minds/2006-0928/

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

Ню-ню.. Теоретик вы наш. Загляните на досуге:

http://blogs.sun.com/brendan/entry/slog_screenshots

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

И сюда тоже загляните:

http://blogs.sun.com/brendan/entry/l2arc_screenshots

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

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

> Ну, теперь понятно почему ZFS такая жручая - требования к памяти и процессору растут пропорционально с объемом стораджа, в отличие от традиционных ФС.

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

>Защитные механизмы есть, но они также предполагают, что после { write(); flush(); } данные уже на диске.

Это всё не то.

Защитные механизмы для серьёзной СУБД должны иметь свойства ACID.
Атомарность (буква A) — это подтверждение (commit) транзакции или неподтверждение (rollback) транзакции — третьего не дано. Всё это — ради непротиворечивости (буква C).

Так вот, в серьёзных СУБД обращения к вызовам write() и flush() входят в состав НЕЗАВЕРШЁННОЙ транзакции. И только после подтверждения записи на диск средствами драйвера операционной системы (с поддержкой "барьеров записи" или собственными механизмами работы СУБД с RAW-носителем) — ради надёжности (буква D) — транзакция помечается ЗАВЕРШЁННОЙ. В любом другом случае СУБД обнаруживает сбой и нуждается в запуске процедуры восстановления целостности базы данных.

Так что пионерия в духе "Oracle на Linux без свойств ACID" — это исключительно дело рук администратора Linux, и уж тем более не свойство файловой системы и "прослойки".

ФС для защитных механизмов СУБД вообще параллельна: вместо ФС может выступать вакуум (утрированный случай) — просто СУБД будет считать все начавшиеся транзакции незавершёнными, вследствие чего СУБД откатит незавершённые транзакции, данные не изменятся, потери данных не произойдёт == принцип ACID не нарушается.

> Так и запишем - в супернадежных линуксовых файловых системах

Именно так :-)

> кэшировать ничего не надо

Да, когда мы работаем с СУБД, именно так дело и обстоит. И для этого у нас в линуксе есть замечательный O_DIRECT. Для СУБД самое оно.

> они и кэширования супербыстры

ZFS умеет кэшировать ввод-вывод Oracle и IDS лучше, чем сами Oracle и IDS?

> И журналы супернадежным и суперскоростным линуксовым файловым системам не нужны - это же точка отказа, ну ее к псам...

Совершенно верно - именно для СУБД (а кому еще нужны транзакционность?) журналы не нужны. По целой куче причин - например, полное журналирование замедляет, и очень существенно, дисковый I/O (двойная запись). СУБД самостоятельно ведет свои собственные журналы, практически не модифицируя метаданные (за исключением mtime и atime), и поэтому профита от журнала не получит.

> Контроль целостности есть и для ZIL'а тоже.

Ну и все - вы опять таки сами только что подтвердили, что при ЛЮБОЙ записи на ZFS процессор будет нагружаться - как минимум просчетом CRC на ZIL. А просчитанные CRC еще надо будет записать, верно? Конечно, за счет относительно маленького размера ZIL нагрузка будет не такая большая... Зато есть интересные циферки - sha256 просчитывает примерно Core2 T7100 просчитывает 90 мегабайт в секунду, C2D E6600 об 2.5 гигагерцах просчитывает 110 мегабайт в секунду. А мы кажется говорили о 200 мегабайтах в секунду? Да без проблем, двухъядерник съедается ZILом и второй двухядерник съедается просчетом контрольных сумм в самой ZFS :-) Ого, а у меня еще 8 активных сессий оракла, пытающихся сделать sort с group by, и еще 60 неактивных, не считая всяких мелких задач. Теперь понятно зачем сану восьмиядерные процессоры - с их то частотами и такими нагрузками по-другому не прокормиться :-)

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

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

> И только после подтверждения записи на диск средствами драйвера операционной системы

Так вот, для посиксово-совместимых ФС это подтверждение является в форме возврата управления из fsync и fdatasync(). Ага, секрет. Хотим провести транзакционную запись? Да без проблем:

write(в журнал СУБД); fdatasync();
помечаем журнал "грязным"; fdatasync();
write(данные); fdatasync();
помечаем журнал чистым; fdatasync();

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

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

И это, насчет fdatasync() - он не нужен для блочных устройств, символьных устройств, и файлов открытых с O_DIRECT, так что тут при прочих равных по скорости классические ФС уделывают ZFS в хлам.

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

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

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

Связаны, но не так сильно, как это наблюдается у ZFS

Ладно, оставим в стороне то, что вы c разговора о файловых системах съехали на базы данных. Для вас, похоже, других приложений, кроме баз данных не существует.

> Ну и все - вы опять таки сами только что подтвердили, что при ЛЮБОЙ записи на ZFS процессор будет нагружаться - как минимум просчетом CRC на ZIL. А просчитанные CRC еще надо будет записать, верно? Конечно, за счет относительно маленького размера ZIL нагрузка будет не такая большая...

Конечно будет. Куда ж деваться, за все нужно платить.

> Зато есть интересные циферки - sha256 просчитывает примерно Core2 T7100 просчитывает 90 мегабайт в секунду, C2D E6600 об 2.5 гигагерцах просчитывает 110 мегабайт в секунду. А мы кажется говорили о 200 мегабайтах в секунду?

Ну это вы говорли о 200 МБ/с. И если вы уж такой гуру ZFS, поделитесь, пожалуйста, как штатными средствами заставить ZIL использовать SHA256.

Хинт - ZIL использует fletcher 2, а его одно ядро вашего любимого C2D посчитает 2ГБ/с с легкостью неимоверной.

Так что опять вы сели в лужу. Не простудитесь.