David Xu поместил (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_core.c) в дерево исходных текстов FreeBSD код альтернативного системам ULE и 4BSD планировщика задач.
Новый o(1) планировщик получил название "CORE". Несмотря на то, что CORE является продолжением развития ULE, алгоритм определения активного процесса в корне изменен (идея заимствована из планировщика в Linux 2.6 ядре (http://josh.trancesoftware.com/linux/)). В новом планировщике реализованы независимые очереди для разных CPU в SMP системе, включая возможность балансировки нагрузки и привязки процесса к определенному процессору (cpu affinity).
При предварительной оценке производительности, используя набор тестов MySQL super-smack (сборка с libthr), новый планировщик показал более высокие результаты производительности, как на однопроцессорных, так и на SMP системах.URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_core.c
Новость: http://www.opennet.ru/opennews/art.shtml?num=7806
Хорошие подвижки, будем ждать результатов.
David Xu вернулся в проект? Это радует, и радует больше чем сам планировщик! :) Хотя и планировщик нужное дело, Давид на этом собаку съел наверное, что-то путное выйдет.
Хорошая новость! И то, что Xu вернулся, и по тому, что он делает. CPU Affinity, кстати, не хватало.
забавно, планировщик из Linux, Dtrace из Solaris...
Get the best
МяФ!:) читайте внимательнее новость, идея взята из... а не сам планеровщик взят из... не путайте идею с конкретной реализацией... только не говорите что FreeBSD только берут у других, холи вары оставим ЛОРу у них там это хорошо получаеться...:)
как будет время - посмотрю что там взято из Линуха, идея или вообще ;)
и вам советую не фанатствовать, а убедиться самому.
Фря уже почти ничего никому не дает. только берет. роль дойных коров теперь у Open Solaris & Linux
sad but true :)
Add scheduler CORE, the work I have done half a year ago, recent,
I picked it up again. The scheduler is forked from ULE, but the
algorithm to detect an interactive process is almost completely
different with ULE, it comes from Linux paper "Understanding the
Linux 2.6.8.1 CPU Scheduler", although I still use same word
"score" as a priority boost in ULE scheduler.
===========================
где говорится что взял алгоритм определения интерактивности из linux шедулера. остальное является фоком ULE.
> Add scheduler CORE, the work I have done half a
>year ago, recent,
> I picked it up again. The scheduler is forked from
>ULE, but the
> algorithm to detect an interactive process is almost completely
> different with ULE, it comes from Linux paper "Understanding the
>
> Linux 2.6.8.1 CPU Scheduler", although I still use same word
>
> "score" as a priority boost in ULE scheduler.
>===========================
>где говорится что взял алгоритм определения интерактивности из linux шедулера. остальное является
>фоком ULE.сенькс :) но я все-таки когда будет время гляну различия... так, ради интереса :)
Даже если бы это было правдой, ничего печального тут нету, даже наоборот.
Не согласен, просто Линукс сообщество настолько озабочено своей собственной крутизной по сравнению со всеми другими, что не желает замечать очевидных преимуществ других платформ.Они разрабатывают, разрабатывают, разрабатывают что-то новенькое, пока раз в два года Торвальдс не скажет: "Стоп, ребятки, а теперь доделываем всё это до конца!"
Эдакий генератор идей получается. Логично, что из этого множества всегда можно найти стОящие вещи.
Самое интересное, что за всей этой разработкой-разработкой-разработкой (блин, почти как Стив Джоббс) они не успевают посматривать на то, что разрабатывают другие.
Яркие примеры: NETGRAPH и GEOM.
>Не согласен, просто Линукс сообщество настолько озабочено своей собственной крутизной по сравнению
>со всеми другими, что не желает замечать очевидных преимуществ других платформ.
>
>
>Они разрабатывают, разрабатывают, разрабатывают что-то новенькое, пока раз в два года Торвальдс
>не скажет: "Стоп, ребятки, а теперь доделываем всё это до конца!"
>
>
>Эдакий генератор идей получается. Логично, что из этого множества всегда можно найти
>стОящие вещи.
>
>Самое интересное, что за всей этой разработкой-разработкой-разработкой (блин, почти как Стив Джоббс)
>они не успевают посматривать на то, что разрабатывают другие.
>
>Яркие примеры: NETGRAPH и GEOM.а нужны ли они реально? :)
в чем плюсы этих подсистем?
в чем "очевидных преимуществ других платформ"?
аналога чему нет в линухе?
GEOM это обший framework для дисковой подсистемы. сколько нибудь близкий аналог lvm & emvs2.
NETGRAPH - это весьма интересная вещь позволяющая строить граф связей между "кубиками" сетевой подсистемы при этом с достаточно высокой производительностью. Аналог в линухе мне не знаком - хотя очень удобно.
>GEOM это обший framework для дисковой подсистемы. сколько нибудь близкий аналог lvm
>& emvs2.чудно. сферический конь? вопрос был: чего он такого может, чего не может линух?
>NETGRAPH - это весьма интересная вещь позволяющая строить граф связей между "кубиками"
>сетевой подсистемы при этом с достаточно высокой производительностью."можно быстро... ыЫыыыы ну, графы, вобщем"
>Аналог в линухе мне не знаком - хотя очень удобно.
пример задачи, которая решаеться с помощью нетграфа и НЕ имеет решения в линухе, плз
В том, что GEOM -- это универсальная прослойка, которая оперирует понятиями "контейнер данных", что позволяет полностью абстрагироваться от используемого накопителя и создавать практически любое хранилище. Что это даёт -- это даёт универсальность, скажем рейд массив можно организовывать разными путями из разных дисков, но в итоге, как GEOM класс он будет выглядеть совершенно одинаково независимо от железа.Про NETGRAPH: тут всё еще лучше и гибче. Данная система представляет собой набор элементарных модулей (unix way), у которых есть входы и выходы (так называемые крючки -- hooks). К этим крючкам можно подсоединять другие модули. Соответственно, обладая базовыми знаниями функционирования протокола, можно реализовать любую обработку трафика в ядре.
Для чего я использую NETGRAPH -- для подсчета большого трафика, и не просто большого, а с большим числом пакетов в секунду. Все решения на libpcap не годятся из-за своей производительности и латентности, которую они вносят в прохождение потока. Также я использую NETGRAPH (а точнее mpd, построенный на нём) для организации до 500 одновременных PPTP туннелей также с большим pps. poptop вводил в ступор машину уже при 100-150 подключениях, причем работать становилось совершенно невозможно.
Еще очень полезная вещь -- это jail окружение -- его использую для виртуальных серверов и очень им доволен.
Хочу еще добавить, что всё это поставляется вместе с системой в стандартной поставке -- поставил и работай, чего нельзя сказать о аналогичных Линукс решениях, где необходимо подобрать ядро, которое всё это будет держать, наложить на него патчей и пересобрать его.
Не надо также думать, что я не использую Линукс в своей работе -- использую там, где считаю это оправданным, или отсутствие поддержки железа не позволяет использовать другую ОС.
Слушай, а ты не можешь поделится опытом, как ты это всё завёл? У меня не получилось настроить mpd и ng_netflow с ng_nat. Если поможешь, буду очень, очень признателен. Вплоть до поставки пива. ;-)
>В том, что GEOM -- это универсальная прослойка, которая оперирует понятиями "контейнер
>данных", что позволяет полностью абстрагироваться от используемого накопителя и создавать практически
>любое хранилище. Что это даёт -- это даёт универсальность, скажем рейд
>массив можно организовывать разными путями из разных дисков, но в итоге,
>как GEOM класс он будет выглядеть совершенно одинаково независимо от железа.т.е. ничего такого, чего нельзя сделать в Линухе.
>Про NETGRAPH: тут всё еще лучше и гибче. Данная система представляет собой
>набор элементарных модулей (unix way), у которых есть входы и выходы
>(так называемые крючки -- hooks). К этим крючкам можно подсоединять другие
>модули. Соответственно, обладая базовыми знаниями функционирования протокола, можно реализовать любую обработку
>трафика в ядре.
>
>Для чего я использую NETGRAPH -- для подсчета большого трафика, и не
>просто большого, а с большим числом пакетов в секунду. Все решения
>на libpcap не годятся из-за своей производительности и латентности, которую они
>вносят в прохождение потока.ну сравнили юзер-левел с ядром.....
>Также я использую NETGRAPH (а точнее mpd,
>построенный на нём) для организации до 500 одновременных PPTP туннелей также
>с большим pps. poptop вводил в ступор машину уже при 100-150
>подключениях, причем работать становилось совершенно невозможно.то же самое: юзер-левел/ядро...
>Еще очень полезная вещь -- это jail окружение -- его использую для
>виртуальных серверов и очень им доволен.
средств виртуализации в линухе выше крыши, и не таких убогих как jail>Хочу еще добавить, что всё это поставляется вместе с системой в стандартной
>поставке -- поставил и работай, чего нельзя сказать о аналогичных Линукс
>решениях, где необходимо подобрать ядро, которое всё это будет держать, наложить
>на него патчей и пересобрать его.очевидно, вы брали шестой редхат...
последние дистры (пятая федора, к примеру) предоставляет Xen виртуализацию "из коробки".
Так что, не нужно пугать людей радиусом кривизны рук и ума
>Не надо также думать, что я не использую Линукс в своей работе
я смотрю, что надо....>-- использую там, где считаю это оправданным, или отсутствие поддержки железа
>не позволяет использовать другую ОС.
>ну сравнили юзер-левел с ядром.....
.
>то же самое: юзер-левел/ядро...Вот и сравнили, прямой ответ на прямой вопрос: линукс некоторые очень нужные вещи НЕ УМЕЕТ делать без юзерлевел костылей для pppd типа poptop или rp-pppoe.
>>ну сравнили юзер-левел с ядром.....
>.
>>то же самое: юзер-левел/ядро...
>
>Вот и сравнили, прямой ответ на прямой вопрос: линукс некоторые очень нужные
>вещи НЕ УМЕЕТ делать без юзерлевел костылей для pppd типа poptop
>или rp-pppoe.дело даже не в этом. если ваша контора обзавелась более 150 позователями онлайн и не в состоянии купить циску... :)
да, правильно, вам прямая дорога к Фре :)
>>ну сравнили юзер-левел с ядром.....
>.
>>то же самое: юзер-левел/ядро...
>
>Вот и сравнили, прямой ответ на прямой вопрос: линукс некоторые очень нужные
>вещи НЕ УМЕЕТну ты еще скажи он роутить не умеет без юзерлевел костыля "ip".
имеющий руки - да насерчит (заняло секунд 10 - ну набрать "poptop linux kernel implementation" в гугле)
>делать без юзерлевел костылей для pppd типа poptop
пить ядъ здесь: http://accel-pptp.sourceforge.net/
>или rp-pppoe.бить свой ленивый лоб ап стену: опция ядра CONFIG_PPPOE
Не знаешь - лучше промолчи
>пить ядъ здесь: http://accel-pptp.sourceforge.net/
поставишь такое в продакшен? самоубийца
>>В том, что GEOM -- это универсальная прослойка, которая оперирует понятиями "контейнер
>>данных", что позволяет полностью абстрагироваться от используемого накопителя и создавать практически
>>любое хранилище. Что это даёт -- это даёт универсальность, скажем рейд
>>массив можно организовывать разными путями из разных дисков, но в итоге,
>>как GEOM класс он будет выглядеть совершенно одинаково независимо от железа.
>
>т.е. ничего такого, чего нельзя сделать в Линухе.
>
За исключением одной вещи. Эти системы дают _стабильный_ API для реализации расширений.
linux стабильного API не предосталяет (исключение netfilter со своими модулями).
А наблюдать как в очередной ветке 2.6 поубирали EXPORT_SYMBOL или сломали API (это внутри стабильной ветки то) весьма забавно.
>>>В том, что GEOM -- это универсальная прослойка, которая оперирует понятиями "контейнер
>>>данных", что позволяет полностью абстрагироваться от используемого накопителя и создавать практически
>>>любое хранилище. Что это даёт -- это даёт универсальность, скажем рейд
>>>массив можно организовывать разными путями из разных дисков, но в итоге,
>>>как GEOM класс он будет выглядеть совершенно одинаково независимо от железа.
>>
>>т.е. ничего такого, чего нельзя сделать в Линухе.
>>
>За исключением одной вещи. Эти системы дают _стабильный_ API для реализации расширений.
>
>linux стабильного API не предосталяет (исключение netfilter со своими модулями).
>А наблюдать как в очередной ветке 2.6 поубирали EXPORT_SYMBOL или сломали API
>(это внутри стабильной ветки то) весьма забавно.пожалуйста, замените слово "стабильный" на слово "постоянный". это уменьшит возможность инсинуаций от ваших младших коллег- любителей БЗД.
>>т.е. ничего такого, чего нельзя сделать в Линухе.
>>
>За исключением одной вещи. Эти системы дают _стабильный_ API для реализации расширений.
>
>linux стабильного API не предосталяет (исключение netfilter со своими модулями).
>А наблюдать как в очередной ветке 2.6 поубирали EXPORT_SYMBOL или сломали API
>(это внутри стабильной ветки то)курите маны, господа. Не нужно без малейшего понимания говорить о "ветке 2.6".
С постоянством API дела в линухе ничуть не хуже чем в БЗДе: не меняется внутри ветки.
Только вот некто не удосужилсо подумать, что такое 2.6 и что такое 2.6.x.
И что в Линухе ветки могут нумероваццо по другому принципу, нежели в бзде.Так вот внутри именно 2.6.x API неизменен. И именно под какую-то конкрутную 2.6.x ветку делаюццо патчи и расширения.
>весьма забавно.
Весьма плачевно такое знание об%ираемого предмета.
>Так вот внутри именно 2.6.x API неизменен. И именно под какую-то конкрутную
>2.6.x ветку делаюццо патчи и расширения.
>
>>весьма забавно.
>
>Весьма плачевно такое знание об%ираемого предмета.
Да нет.. критика называется уже обсиранием? тогда позволю показать некоторую статистику.
Патч взят случайный. Можете сами проверить
# zcat /mnt/tmp/3/patch-2.6.11.gz | grep '^-EXPORT' | wc -l
380
# zcat /mnt/tmp/3/patch-2.6.11.gz | grep '^+EXPORT' | wc -l
644
Пример
-EXPORT_SYMBOL_GPL(xfrm_aalg_get_byidx);
-EXPORT_SYMBOL_GPL(xfrm_ealg_get_byidx);
-EXPORT_SYMBOL_GPL(xfrm_calg_get_byidx);
-EXPORT_SYMBOL_GPL(xfrm_aalg_get_byid);
-EXPORT_SYMBOL_GPL(xfrm_ealg_get_byid);
-EXPORT_SYMBOL_GPL(xfrm_calg_get_byid);
-EXPORT_SYMBOL_GPL(xfrm_aalg_get_byname);
-EXPORT_SYMBOL_GPL(xfrm_ealg_get_byname);
-EXPORT_SYMBOL_GPL(xfrm_calg_get_byname);
-EXPORT_SYMBOL_GPL(skb_icv_walk);
+EXPORT_SYMBOL(__secpath_destroy);
+EXPORT_SYMBOL(secpath_dup);
+EXPORT_SYMBOL(xfrm_parse_spi);
+EXPORT_SYMBOL(xfrm_cfg_sem);
+EXPORT_SYMBOL(xfrm_policy_list);
+EXPORT_SYMBOL(xfrm_register_type);
+EXPORT_SYMBOL(xfrm_unregister_type);
+EXPORT_SYMBOL(xfrm_get_type);
+EXPORT_SYMBOL(xfrm_dst_lookup);
+EXPORT_SYMBOL(xfrm_policy_alloc);
+EXPORT_SYMBOL(__xfrm_policy_destroy);
+EXPORT_SYMBOL(xfrm_policy_insert);
+EXPORT_SYMBOL(xfrm_policy_bysel);
+EXPORT_SYMBOL(xfrm_policy_byid);
+EXPORT_SYMBOL(xfrm_policy_flush);
+EXPORT_SYMBOL(xfrm_policy_walk);насколько я вижу для xfrm (aka IPSEC) были измены имена экспортируемых функций. Теперь вопрос является ли такая смена сменой кернельного API? Или до сих пор считаем что API в 2.6 ветке не изменен?
>насколько я вижу для xfrm (aka IPSEC) были измены имена экспортируемых функций.
>Теперь вопрос является ли такая смена сменой кернельного API? Или до
>сих пор считаем что API в 2.6 ветке не изменен?товарисч, вы ЧИТАТЬ умеете??
перечитайте, плз, МОЙ пост еще раз.
А конкретно то место, где сказано, что API сохраняется НЕ внутри 2.6 ветки, а внутри 2.6.х веток.Т.е. по-русски: в версии 2.6.11 (из вашего примера), берем патч с 2.6.11 на 2.6.11.12 - т.е. внутри гарантированного API (изменение EXTRAVERSION):
http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.12.bz2смотрим:
> bzcat patch-2.6.11.12.bz2 |egrep '^.(EXPORT|SUBLEVEL|EXTRAVERSION)'
SUBLEVEL = 11
-EXTRAVERSION =
+EXTRAVERSION = .12
+EXPORT_SYMBOL_GPL(blkdev_ioctl);
EXPORT_SYMBOL(get_unmapped_area);
+EXPORT_SYMBOL(tcp_timer_bug_msg);и видим ДОБАВЛЕНИЕ функционала, старый НИКУДА не девается. Вам так дорогая совместимость API остаеццо нетронутой.
А то, что вы взяли - это патч МЕЖДУ ветками (с 2.6.10 на 2.6.11 - изменение SUBLEVEL),
и там НИКТО не обещал совместимости:
http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.bz2(EXPORTS считать не буду - вы их показали достаточно наглядно):
> bzcat patch-2.6.11.bz2 |egrep '^.(SUBLEVEL|EXTRAVERSION)'
-SUBLEVEL = 10
+SUBLEVEL = 11
EXTRAVERSION =
Так что лучше помалкивать, если родом из танка
>>насколько я вижу для xfrm (aka IPSEC) были измены имена экспортируемых функций.
>>Теперь вопрос является ли такая смена сменой кернельного API? Или до
>>сих пор считаем что API в 2.6 ветке не изменен?
>
>товарисч, вы ЧИТАТЬ умеете??
>
>перечитайте, плз, МОЙ пост еще раз.
>А конкретно то место, где сказано, что API сохраняется НЕ внутри 2.6
>ветки, а внутри 2.6.х веток.
>
>Т.е. по-русски: в версии 2.6.11 (из вашего примера), берем патч с 2.6.11
>на 2.6.11.12 - т.е. внутри гарантированного API (изменение EXTRAVERSION):
>http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.12.bz2
>
>смотрим:
>> bzcat patch-2.6.11.12.bz2 |egrep '^.(EXPORT|SUBLEVEL|EXTRAVERSION)'
> SUBLEVEL = 11
>-EXTRAVERSION =
>+EXTRAVERSION = .12
>+EXPORT_SYMBOL_GPL(blkdev_ioctl);
> EXPORT_SYMBOL(get_unmapped_area);
>+EXPORT_SYMBOL(tcp_timer_bug_msg);
>
>и видим ДОБАВЛЕНИЕ функционала, старый НИКУДА не девается. Вам так дорогая совместимость
>API остаеццо нетронутой.
>
2.6.x.y - являются bugfix release. если уж и там меняют чтото то это уже хавайсь.
начнем с того что .y появилась относительно недавно - когда количество багов в X. версии перевисило некоторый придел и люди не захотели ждать исправлений в следующем релизе.
но с точки зрения lkml и маинтайнера 2.6 ветки - релизами является .X составляющая номера.
Советую слегка ознакомиться в историей.
Ветки 2.6.x не существует в природе, она существует только пока не инкрементировали x составляющую номера. Если вы сможете привести факты где показывается что ветка 2.6.x.y продолжала свое развитие после выхода 2.6.(x+1) версии - я с удовольствием послушаю.
>2.6.x.y - являются bugfix release. если уж и там меняют чтото то
>это уже хавайсь.
>начнем с того что .y появилась относительно недавно - когда количество багов
>в X. версии перевисило некоторый придел и люди не захотели ждать
>исправлений в следующем релизе.
>но с точки зрения lkml и маинтайнера 2.6 ветки - релизами является
>.X составляющая номера.
>Советую слегка ознакомиться в историей.
>Ветки 2.6.x не существует в природе, она существует только пока не инкрементировали
>x составляющую номера. Если вы сможете привести факты где показывается что
>ветка 2.6.x.y продолжала свое развитие после выхода 2.6.(x+1) версии - я
>с удовольствием послушаюинтересно наблюдать за тем как у бздшника не укладывается в голове политика нумерации релизов отличная от бзд :)
технические моменты разобраны. остальное - дело вкуса ;)
>>Советую слегка ознакомиться в историей.
>>Ветки 2.6.x не существует в природе, она существует только пока не инкрементировали
>>x составляющую номера. Если вы сможете привести факты где показывается что
>>ветка 2.6.x.y продолжала свое развитие после выхода 2.6.(x+1) версии - я
>>с удовольствием послушаю
>
>интересно наблюдать за тем как у бздшника не укладывается в голове политика
>нумерации релизов отличная от бзд :)
>
>технические моменты разобраны. остальное - дело вкуса ;)
да?
http://en.wikipedia.org/wiki/Linux_kernel
раздел - Version numbering.
4я цифра появилоась после 2.6.8 и означает только bugix release. аналог -p релизов в фре.
процитирую
===
The version number of the Linux kernel currently consists of four numbers, following a recent change in the long-standing policy of a three-number versioning scheme. For illustration, let it be assumed that the version number is composed thus: A.B.C[.D] (e.g. 2.2.1, 2.4.13 or 2.6.12.3).* The C number indicates the minor revision of the kernel. In the old three-number versioning scheme, this was changed when security patches, bugfixes, new features or drivers were implemented in the kernel. With the new policy, however, it is only changed when new drivers or features are introduced; minor fixes are handled by the D number.
* A D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimize the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Bug-fixes and security patches are now managed by the fourth number, whereas bigger changes are only implemented in minor revision changes (the C number).
===
>>> A D number first occurred when a grave error, which required immediate fixing <<<
:)
не пойму кому вы пытаетесь глаза открыть.
я это все знал как раз с 2.6.8, когда появилась 4 цифра.> 4я цифра появилоась после 2.6.8 и означает только bugix release. аналог -p релизов в фре.
не уверен насчет аналога. Никто не стремился быть аналогом для фри :)
Хотя не пойму почему наличие 4 знака версии обязывает 2.6 ветку быть неизменной в API или чем бы то ни было :)
Ну не нравиццо вам это - ясное дело. Потому что во фре не так :)
ну так это же ваши проблемы ;)
>>>т.е. ничего такого, чего нельзя сделать в Линухе.
>>>
>>За исключением одной вещи. Эти системы дают _стабильный_ API для реализации расширений.
>>
>>linux стабильного API не предосталяет (исключение netfilter со своими модулями).
>>А наблюдать как в очередной ветке 2.6 поубирали EXPORT_SYMBOL или сломали API
>>(это внутри стабильной ветки то)
>
>курите маны, господа. Не нужно без малейшего понимания говорить о "ветке 2.6".
>
>С постоянством API дела в линухе ничуть не хуже чем в БЗДе:
>не меняется внутри ветки.
>Только вот некто не удосужилсо подумать, что такое 2.6 и что такое
>2.6.x.
>И что в Линухе ветки могут нумероваццо по другому принципу, нежели в
>бзде.
>
>Так вот внутри именно 2.6.x API неизменен. И именно под какую-то конкрутную
>2.6.x ветку делаюццо патчи и расширения.
>
>>весьма забавно.
>
>Весьма плачевно такое знание об%ираемого предмета.АПИ действительно слегка меняется. правда, не настолько критично, как об этом думает "Алексей". :) например, они слегка изменили поля в структуре TTY в 2.6.12. мой драйвер не собирался. чтобы он собрался и заработал мне потребовалось 30 минут времени (на то, чтобы выснить что же там случилось) и 1 ifdef чтобы все заработало. :)
>
>АПИ действительно слегка меняется. правда, не настолько критично, как об этом думает
>"Алексей". :) например, они слегка изменили поля в структуре TTY в
>2.6.12. мой драйвер не собирался. чтобы он собрался и заработал мне
>потребовалось 30 минут времени (на то, чтобы выснить что же там
>случилось) и 1 ifdef чтобы все заработало. :)
тебе повезло нарваться на маленькое изменение - в некоторых случаях переход между 2.6.x & 2.6.(x+1) весьма болезнен.
>>
>>АПИ действительно слегка меняется. правда, не настолько критично, как об этом думает
>>"Алексей". :) например, они слегка изменили поля в структуре TTY в
>>2.6.12. мой драйвер не собирался. чтобы он собрался и заработал мне
>>потребовалось 30 минут времени (на то, чтобы выснить что же там
>>случилось) и 1 ifdef чтобы все заработало. :)
>тебе повезло нарваться на маленькое изменение - в некоторых случаях переход между
>2.6.x & 2.6.(x+1) весьма болезнен.это вы как driver developer говорите?
>Весьма плачевно такое знание об%ираемого предмета.Глянь на тред и осознай кто кого обсирает без знания предмета.
Линух ты сюда (GEOM,NETGRAPH) прикрутил ради флейма.В линухе нет аналогов этих модульных механизмов.
Другое дело, что ты просто не понимаешь зачем это нужно. Для тебя нет разницы между ладно устроеным домом и домом на подпорках - "какая разница? и там и там можно жить".
>>Весьма плачевно такое знание об%ираемого предмета.
>
>Глянь на тред и осознай кто кого обсирает без знания предмета.
>Линух ты сюда (GEOM,NETGRAPH) прикрутил ради флейма.
>
>В линухе нет аналогов этих модульных механизмов.
>Другое дело, что ты просто не понимаешь зачем это нужно. Для тебя
>нет разницы между ладно устроеным домом и домом на подпорках -
>"какая разница? и там и там можно жить".я понимаю, конечно, что во фре есть хорошие вещи. и они неплохо сделаны.
и это geom & netgraf и может быть что-то еще... :)
только вот ваша грусть состоит в том, что в попу они мало кому уперлись.
я реально не вижу причин использовать эти вещи в серьезных задачах.
например:
GEOM. используем хардварные рейды, софтварные рейды, lvm, GFS (очень, кстати, необходимая вещь, аналога которой во Фре нет)
NetGraph. используем стандартные (или нестандартные) линуксовые сервера pppoe/pptp, как только кол-во клиентов более лимита - у нас уже есть деньги на покупку (пусть даже БУшной) кошки.какими бы замечательными не были geom & netgraph, они не критически необходимы.
я за разеление труда: пусть маршрутизацией рулят кошки, у них это получается лучше всех, пусть данные хранятся на хардварных рейдах, подключенных через GFS, например и пусть все остальное будет серверами приложений или PC на линуксе и вин.
все остальное - от бедности и от лукавого
>я за разеление труда: пусть маршрутизацией рулят кошки, у них это получается
>лучше всех, пусть данные хранятся на хардварных рейдах, подключенных через GFS,
>например и пусть все остальное будет серверами приложений или PC на
>линуксе и вин.
>все остальное - от бедности и от лукавоготогда линукс выкидываем - судя по количеству пользователей винда круче, и по вашей логике линукс ненужен
P.S. в маршрутизации рулят не кошки а джуниперы...
>>я за разеление труда: пусть маршрутизацией рулят кошки, у них это получается
>>лучше всех, пусть данные хранятся на хардварных рейдах, подключенных через GFS,
>>например и пусть все остальное будет серверами приложений или PC на
>>линуксе и вин.
>>все остальное - от бедности и от лукавого
>
>тогда линукс выкидываем - судя по количеству пользователей винда круче, и по
>вашей логике линукс ненужен
>
>P.S. в маршрутизации рулят не кошки а джуниперы...не надо утрировать, вы прекрасно поняли о чем я говорю
>>GEOM это обший framework для дисковой подсистемы. сколько нибудь близкий аналог lvm
>>& emvs2.
>
>чудно. сферический конь? вопрос был: чего он такого может, чего не может
>линух?Экспортировать, скажем, физический накопитель по сети, линукс может? Представьте себе эдакий распределенный по нескольким машинам RAID.
>>Аналог в линухе мне не знаком - хотя очень удобно.
>
>пример задачи, которая решаеться с помощью нетграфа и НЕ имеет решения в
>линухе, плзНу к примеру соорудить на роутере бридж с транком из 4-х ethernet-каналов в соседнюю сетку и третьей частью бриджа связать эти сетки по udp-туннелю с удаленным офисом. На нетграфе - легко и изящно.
>>NETGRAPH - это весьма интересная вещь позволяющая строить граф связей между "кубиками"
>>сетевой подсистемы при этом с достаточно высокой производительностью.
>
>"можно быстро... ыЫыыыы ну, графы, вобщем"Вы правда не понимаете разницы между общими стройными решениями, и набором мелких хаков под несколько конкретных задач? Netgraph и GEOM, ввиду высокого уровня абстракции, позволяют достаточно легко решать самые разные задачи, которые другими средствами, возможно, решаются (если решаются) через глубокую жопу. Я специально привел достаточно экзотические примеры (на практике, пожалуй геом чаще используют для обычных программных RAID'ов, а нетграф - для подсчета трафика и VPN): расширяемость есть большой плюс - сегодня вам хватает стандартных задач, завтра вам нужно что-то большее, и если вы можете сделать это тем же инструментом, честь и хвала такому инструменту.
>Экспортировать, скажем, физический накопитель по сети, линукс может?
см. ядро: CONFIG_BLK_DEV_NBD
Стал уметь намного раньше, чем геом начал зарождаццо в головах бздюшнеков>Представьте себе эдакий распределенный по нескольким машинам RAID.
ну и с райдами все хорошо.
А вообще-то - GFS ;) а вот бздя таким похвастаццо не может....>Ну к примеру соорудить на роутере бридж с транком из 4-х ethernet-каналов
>в соседнюю сетку и третьей частью бриджа связать эти сетки по
>udp-туннелю с удаленным офисом. На нетграфе - легко и изящно.
ну мост - не вопрос, а туннель либо vtun, либо openvpn.
Не слишком изящно и не полностью на кернел левеле.
Надеюсь, в нетграфе вопрос сжатия, шифрования и фильтрации бриджевого траффика решен.Любопытно посмотреть на решение на нетграфе.
>Вы правда не понимаете разницы между общими стройными решениями, и набором мелких
>хаков под несколько конкретных задач?Ну, покажите мне красоту нетграфа ;)
>Netgraph и GEOM, ввиду высокого уровня
>абстракции, позволяют достаточно легко решать самые разные задачи, которые другими средствами,
>возможно, решаются (если решаютсяпримеры без решения, плз в студию
>) через глубокую жопу. Я специально привел достаточно
>экзотические примеры (на практике, пожалуй геом чаще используют для обычных программных
>RAID'ов, а нетграф - для подсчета трафика и VPN): расширяемость есть
>большой плюс - сегодня вам хватает стандартных задач, завтра вам нужно
>что-то большее, и если вы можете сделать это тем же инструментом,
>честь и хвала такому инструменту.на TUN/TAP драйвере можно много чего построить ;)
И если хвала этому инструменту спорный для вас вопрос - примеры плз :)
>>Экспортировать, скажем, физический накопитель по сети, линукс может?
>см. ядро: CONFIG_BLK_DEV_NBD
>Стал уметь намного раньше, чем геом начал зарождаццо в головах бздюшнековСсылочку на дату не затруднит? Геом "начал зарождаться в головах" лет эдак 6 назад.
>>Представьте себе эдакий распределенный по нескольким машинам RAID.
>ну и с райдами все хорошо.
>А вообще-то - GFS ;) а вот бздя таким похвастаццо не может....А обернуть это сжатием и шифрованием - может?
>>Ну к примеру соорудить на роутере бридж с транком из 4-х ethernet-каналов
>>в соседнюю сетку и третьей частью бриджа связать эти сетки по
>>udp-туннелю с удаленным офисом. На нетграфе - легко и изящно.
>ну мост - не вопрос, а туннель либо vtun, либо openvpn.
>Не слишком изящно и не полностью на кернел левеле.Именно. Да и openvpn - та еще гавняга.
>Надеюсь, в нетграфе вопрос сжатия, шифрования и фильтрации бриджевого траффика решен.
Вот. "бриджевого". Вы постоянно думаете в терминах конкретных задач, и не пытаетесь придумать общее решение. А в нетграфе - если у нас написана нода ng_mppc, так мы её можем воткнуть куда угодно. В бридж, значит в бридж. В один из каналов транка - значит, в него. Это, поясняя по аналогии, если у нас есть pipeline "cat file | sort | uniq | someproga", то мы берем и вставляем "| grep substr" в него куда хотим.
>Любопытно посмотреть на решение на нетграфе.
ng_one2many(4)
ng_bridge(4)
ng_ksocket(4)
more /usr/share/examples/netgraph/*>>Вы правда не понимаете разницы между общими стройными решениями, и набором мелких
>>хаков под несколько конкретных задач?
>
>Ну, покажите мне красоту нетграфа ;)Почитайте маны. А также туториалы/введения, типа http://www.citrin.ru/daemonnews/netgraph.html
>>Netgraph и GEOM, ввиду высокого уровня
>>абстракции, позволяют достаточно легко решать самые разные задачи, которые другими средствами,
>>возможно, решаются (если решаются
>
>примеры без решения, плз в студиюЯ не настолько хорошо разбираюсь в линуксе, чтоб отличить задачу, не имеющую в нем решения, от имеющую решение методом вырезания гланд автогеном через задний проход. Ну хорошо, допустим у нас в транке два разнородныз канала, и надо пакеты с определенным диапазоном размеров пихать в один, остальные в другой. А если усложнить критерий и разделять пакеты по результатам простого (per-packet) L7-анализа, описываемого на языке tcpdump, к примеру?
>>) через глубокую жопу. Я специально привел достаточно
>>экзотические примеры (на практике, пожалуй геом чаще используют для обычных программных
>>RAID'ов, а нетграф - для подсчета трафика и VPN): расширяемость есть
>>большой плюс - сегодня вам хватает стандартных задач, завтра вам нужно
>>что-то большее, и если вы можете сделать это тем же инструментом,
>>честь и хвала такому инструменту.
>
>на TUN/TAP драйвере можно много чего построить ;)
>И если хвала этому инструменту спорный для вас вопрос - примеры плз
>:)Не вижу достаточного уровня абстракции. Соответственно, много - это сколько?
>Ссылочку на дату не затруднит? Геом "начал зарождаться в головах" лет эдак
>6 назад.да... свежа реализация
>>>Представьте себе эдакий распределенный по нескольким машинам RAID.
>>ну и с райдами все хорошо.
>>А вообще-то - GFS ;) а вот бздя таким похвастаццо не может....
>
>А обернуть это сжатием и шифрованием - может?
IPSEC никто не отменял>Вот. "бриджевого". Вы постоянно думаете в терминах конкретных задач, и не пытаетесь
>придумать общее решение. А в нетграфе - если у нас написана
>нода ng_mppc, так мы её можем воткнуть куда угодно. В бридж,
>значит в бридж. В один из каналов транка - значит, в
>него. Это, поясняя по аналогии, если у нас есть pipeline "cat
>file | sort | uniq | someproga", то мы берем и
>вставляем "| grep substr" в него куда хотим.
>>Любопытно посмотреть на решение на нетграфе.
>
>ng_one2many(4)
>ng_bridge(4)
>ng_ksocket(4)
>more /usr/share/examples/netgraph/*
>
>Почитайте маны. А также туториалы/введения, типа
>http://www.citrin.ru/daemonnews/netgraph.htmlда, вопросов не имею. Структуры типа нетграфа в линухе нет.
И нечем заменить функционал нетграфа все-таки... (ну убейте меня, товарищи по фронту,
но я реально не знаю чем это заменить в линухе)
Нетграф - свежее решение, проектировалось относительно недавно и с учетом
существующих проблем. Такого для линуха сделано не было пока что.
Но, ваша широкая лицензия не ставит границ портирования нетграфа в линух ;)
может это и случатсо когда-нить, если кому-то реально понадобится.>Я не настолько хорошо разбираюсь в линуксе, чтоб отличить задачу, не имеющую
>в нем решения, от имеющую решение методом вырезания гланд автогеном через
>задний проход. Ну хорошо, допустим у нас в транке два разнородныз
>канала, и надо пакеты с определенным диапазоном размеров пихать в один,
>остальные в другой. А если усложнить критерий и разделять пакеты по
>результатам простого (per-packet) L7-анализа, описываемого на языке tcpdump, к примеру?
да, это все - большие проблемы для линуха.
>да, вопросов не имею. Структуры типа нетграфа в линухе нет.
>И нечем заменить функционал нетграфа все-таки... (ну убейте меня, товарищи по фронту,
>но я реально не знаю чем это заменить в линухе)
а и не нужно это никому за N редкими извращенцами :) сеть надо просто аккуратно проектировать чтоб без извращений обходиться.вот реальная задача:
имеется хардварный рейд c двумя SCSI-интерфейсами. требуется: расшарить файловую систему для почтаря (postfix) на две тачки под БЗД. условия: изменения в файловой системе должны видеться сразу с обеих тачек.
nfs и пр. сосут в такой конфигурации.
подозреваю, геомом тоже бравировать в этом случае смысла нет. :)
>вот реальная задача:
>имеется хардварный рейд c двумя SCSI-интерфейсами. требуется: расшарить файловую систему для почтаря
>(postfix) на две тачки под БЗД. условия: изменения в файловой системе
>должны видеться сразу с обеих тачек.
>nfs и пр. сосут в такой конфигурации.
>подозреваю, геомом тоже бравировать в этом случае смысла нет. :)
drbd-то выпендриваетесь?
>>вот реальная задача:
>>имеется хардварный рейд c двумя SCSI-интерфейсами. требуется: расшарить файловую систему для почтаря
>>(postfix) на две тачки под БЗД. условия: изменения в файловой системе
>>должны видеться сразу с обеих тачек.
>>nfs и пр. сосут в такой конфигурации.
>>подозреваю, геомом тоже бравировать в этом случае смысла нет. :)
>drbd-то выпендриваетесь?ни чуть. реальная задача. решали 2 месяца назад. ваши варианты для BSD?
>как будет время - посмотрю что там взято из Линуха, идея или
>вообще ;)
>и вам советую не фанатствовать, а убедиться самому.
>Фря уже почти ничего никому не дает. только берет. роль дойных коров
>теперь у Open Solaris & Linux
>sad but true :)
Это хорошо что вы не забываете, что стране нужен метан.....
>>как будет время - посмотрю что там взято из Линуха, идея или
>>вообще ;)
>>и вам советую не фанатствовать, а убедиться самому.
>>Фря уже почти ничего никому не дает. только берет. роль дойных коров
>>теперь у Open Solaris & Linux
>>sad but true :)
>Это хорошо что вы не забываете, что стране нужен метан.....а вы, собственно, чего тут сидите? :)
Что они за линукс этот взялись ?- тенденция показывает что останиться один линукс и все да печально,,,,,,,,
Да ничего страшного. Просто много программеров работает под Linux, ну что тут сделаешь? Хорошие вещи надо пертягивать и внедрять, а не вздыхать, что это Linux\Solaris\etc.
Я бы к примеру ext3 хотел бы видеть во фряхе нетолько как модуль, но и как FS для установки фряхи. Там есть много вкусностей, к которым UFS2 еще добираться. Или туже UFS от Solaris. Но здесь врят ли поделяться :) Sun иногда очень жадный :). И таких вещей каждый назовет очень много, кто пользуется в работе обоими системами.
Есть конечно вкусности во фряхе, которых нет в линусяторе... Но, нельзя на этом зацикливаться, надо просто хорошие вещи перетягивать и пользоваться. Фряха от этого не пострадает,а наоборот - улучшиться. И поклонников больше появится
Нда... Не дай вам бог ext3 в качестве базовой ФС. Ну, она конечно лучше UFS2, но все же. Лучше уж reiserfs доводить. Кстати, у МакКусика, на этапе концептуального проектирование UFS, были мсли перетащить reiserfs или XFS и не страдать фигней. Но выбор был сделан в пользу стабильности кода UFS, на котором UFS2 и стоит.
стабильность UFS (with Soft Updates) это очень смешная шутка! :) хотя может на однопроцесорной системе - да. но "жаль", таких уже нет :)"гыгы".
стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут хвалили - и который (видимо забывают) разрабатывался за деньги.
А SU на UFS по сути этот тот же журнал - только в памяти, а не на диске. Желающие могут посмотреть в коде UFS/VFS его работу.
>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>хвалили - и который (видимо забывают) разрабатывался за деньги.
>А SU на UFS по сути этот тот же журнал - только
>в памяти, а не на диске. Желающие могут посмотреть в коде
>UFS/VFS его работу.далека от идеала? стабильность? не повторяйте слова старших коллег, попробуйте сами :)
>>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>>хвалили - и который (видимо забывают) разрабатывался за деньги.
>>А SU на UFS по сути этот тот же журнал - только
>>в памяти, а не на диске. Желающие могут посмотреть в коде
>>UFS/VFS его работу.
>
>далека от идеала? стабильность? не повторяйте слова старших коллег, попробуйте сами :)
>
Мисье уже сам разработал много файловых систем что начинает учить других?
>>>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>>>хвалили - и который (видимо забывают) разрабатывался за деньги.
>>>А SU на UFS по сути этот тот же журнал - только
>>>в памяти, а не на диске. Желающие могут посмотреть в коде
>>>UFS/VFS его работу.
>>
>>далека от идеала? стабильность? не повторяйте слова старших коллег, попробуйте сами :)
>>
>Мисье уже сам разработал много файловых систем что начинает учить других?просто мисье постоянно использует журналируемые файловые системы линукс с момента их появления на серверах и PC.
>>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>>хвалили - и который (видимо забывают) разрабатывался за деньги.
>>А SU на UFS по сути этот тот же журнал - только
>>в памяти, а не на диске. Желающие могут посмотреть в коде
>>UFS/VFS его работу.
>
>далека от идеала? стабильность? не повторяйте слова старших коллег, попробуйте сами :)
>Наблюдал как развалилась ext3. И на мой невинный вопрос "а как же журнал?" чуть не был убит нашим линуксойдом :)
>>>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>>>хвалили - и который (видимо забывают) разрабатывался за деньги.
>>>А SU на UFS по сути этот тот же журнал - только
>>>в памяти, а не на диске. Желающие могут посмотреть в коде
>>>UFS/VFS его работу.
>>
>>далека от идеала? стабильность? не повторяйте слова старших коллег, попробуйте сами :)
>>
>
>Наблюдал как развалилась ext3. И на мой невинный вопрос "а как же
>журнал?" чуть не был убит нашим линуксойдом :)а вы уверены что винт не сыпался как раз в тот момент, когда вы язвительно интересовались про журналы? а то, знаете ли, я встречал таких товарищей... вы не из этой категории? :)
>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>хвалили - и который (видимо забывают) разрабатывался за деньги.
>А SU на UFS по сути этот тот же журнал - только
>в памяти, а не на диске.а толку от памяти, сброшенной при фейле питания? (не нада орать про упсы в этом месте, не о том говорим)
>Желающие могут посмотреть в коде
>UFS/VFS его работу.
>>стабильность журналируемых FS в linux далека от идеала. даже ReiserFS который тут
>>хвалили - и который (видимо забывают) разрабатывался за деньги.
>>А SU на UFS по сути этот тот же журнал - только
>>в памяти, а не на диске.
>
>а толку от памяти, сброшенной при фейле питания? (не нада орать про
>упсы в этом месте, не о том говорим)
>
Она не закомичена и осталась в памяти, в этом случае это равознозначно откату последней транзакции. собственно как и в случае с журналом наибольшая проблема если пропадаление питание происходит на момент комита транзакции, в этом случае у линуха с журналом и у UFS/SU появляется проблемы на FS. журнал же (в той реализации как на ext3) это дикий костыль который приводил (надеюсь уже не приводит) в некоторых случаях к deadlock при включеных дисковых квотах. Детали можно посмотреть fs/ext3/*
>Она не закомичена и осталась в памяти, в этом случае это равознозначно
>откату последней транзакции. собственно как и в случае с журналом наибольшая
>проблема если пропадаление питание происходит на момент комита транзакции, в этом
>случае у линуха с журналом и у UFS/SU появляется проблемы на
>FS. журнал же (в той реализации как на ext3) это дикий
>костыль который приводил (надеюсь уже не приводит) в некоторых случаях к
>deadlock при включеных дисковых квотах. Детали можно посмотреть fs/ext3/*дикие тормоза, к которым приводит использование UFS (пока еще не надеюсь, что не приводит) - есть причиной бессмысленной потери времени. Детали - на freebsd.org
(звучит точно так же)
> Есть конечно вкусности во фряхе, которых нет в линусяторе...URL/пример в студию
Как раз наоборот. Пускай пенгвины занимаются тестированием, а стабле поюзаем на *BSD. :P
Мой ответ был к предыдущему оратору.
>Как раз наоборот. Пускай пенгвины занимаются тестированием, а стабле поюзаем на *BSD.
>:Pлет через 10 :)
ЛЮДИ! Вы хуже старых бабок, жрущщих семечки около подьезда. бухахах, создайте ветку типа "выяснение истинных размеров гениталий пингвинов и дьяволов методом "Язычок". Кто что кому доказал совершенно непонятно ))))) ибо каждый осталсо при своем мнении. Да и плюс ко всему, ну человеки, ну срите на ЛОРе а?))) давайте не будем эти "вкусности" с лора сюда тащить.