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

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

А как ты догадался? Что, по-твоему, должен делать админ локалхоста, чтобы вклиниться в разговор двух гуру, имеющими смутные предстваления об используемых технологиях друг друга?

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

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

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

> GEOM и NetGraph?
ГЕОМ еще ничего, вроде, правда я тут не эксперт тоже. а вот нетграф бяка. сразу скажу, _архитектурно_. ну кто так строит? конечно, свои задачи он решает хорошо, и многим действительно нужен.

>ну блин. я дал тебе выкладку всех вариантов. подумай.

Проблема в том, что я (пока еще) не спец по pf.
И самый тщательный мыслительный процесс приведет к неверным результатам, если он построен на неверных предпосылках :)

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

Эх. То ли я туплю, то ли ты постоянно контекст беседы забываешь.
Суть моего вопроса состояла в следующем: «Можно ли обеспечить пропуск вспомогательных соединений через тот же канал, что и основное, при условии выбора канала на основании некоторого алгоритма (например, случайного)?».

Может, конечно, это я такой тупой... Но совсем-совсем не понимаю, как здесь поможет тег, если он общий для всех соединений.
Допустим, клиент установил одно управляющее соединение через один канал. И еще одно через другой. Можно ли с помощью pf (и сетевой подсистемы OpenBSD) обеспечить, чтобы соединения данных для первой сессии ли через первого провайдера, а для второй — через второго?

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

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

s/таsticky-address/sticky-address/1

Хм. Насколько я понял,
>sticky-address can be specified to ensure that multiple connections from the same source are mapped to the same redirection address.
это вовсе не заставит ходить _весь_ трафик одного хоста через одного провайдера — привязки создаются по паре источник-назначение. То есть все классно.

Спасибо за идею, буду иметь в виду.

> the same source are mapped to the same redirection address
то есть, адрес ната. по крайней мере для редиректа (по сути тот же нат) это работает именно так как я написал. возможно, для обычного ната маппится пара сорс-получатель, я не проверял. надо будет глянуть, кстати.

>>> Можно тест, из результатов которого будет видно что zfs пишет блоками по 1М? ) >> А если будет видно, что пишутся куски 800КБ или 2МБ, это будет считаться?  >Вполне. Прошу.

Посыпаю голову пеплом. Текущее значение параметра, определяющего предельный размер для аггрегации - аккурат максимальный размер блока, то есть 128КБ. Надо будет попробовать с ним поиграться. Я почему-то думал, что оно побольше.

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

Зависит, например, от значения max_phys для системы и/или sd/ssd драйвера

получаем связку kvm + PF

а это как???

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

А такая ужасно тормозная Ниагара 2 считает SHA256 со скоростью 41 GBit/s ;-) Так что понадобится примерно 50 штук "C2D E6600 об 2.5 гигагерцах" чтобы они смогли тягаться с одной тормозной Ниагарой 2.

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

>Посыпаю голову пеплом

Эх, а я так надеялся.

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

> Зависит, например, от значения max_phys для системы и/или sd/ssd драйвера

Конкретный пример не помешал бы. Но не хочется снова заставлять сыпать пепел на голову :)