Клятвенно обещаю все узнать, всему научится, только избавьте нас от "общих способах решения", принятых в ms-dos'е :)))
Ну, комедия, и кому я несколькими постами ранее писал про иноды в ufs..
..ушел перечитывать Таненбаума..
Да-да. А я напишу, что freebsd-шники свою систему понимают по опыту работы с MS-DOS :))
меня пакетрейт потому и интересовал, в таких случаях с мелкими пакетами в него все и упирается.
Абсолютно серьезно готовы оплатить бюджет разработки gfs/ocfs? Redhat свой gfs скрипя тянет.
Ох, какое коварное железо :))
То, что reiserfs стал для Вам мерилом обычного в линуксе. И намекал на его экзотичность даже у самих линуксоидов. В reiserfs еще много других сюрпризов.
Хотите так решать зачаду - решайте, можете оставить меня в лесу с моим карпизным желанием решать задачи с необходимой в каждом отдельном случае детальностью. Понятие stack, видимо, зря придумывали - какая к черту разница на каком уровне случается проблема.
Не меньше, чем Вы в пингвинах с деревьями и коварстве железа :)
Предлагаю все-таки, начать детально разбирать проблемы, отличать одно от второго и не делать вредные обобщения.
Только после того, как начнете "детально разбирать проблемы, отличать одно от второго и не делать вредные обобщения"
тем, хотя бы, что прерывания есть, приоритеты, ioctl рутина и т.п. Драйверы у нас чем занимаются?
Да, такой возможности может не быть. Но ошибочно утверждать, что ее нет вообще.
Так Вы не сваливайте все в кучу, нет у меня желания ее разгребать. Ваше "как обычно" я оценил в истории с reiserfs.
Все что вы описали, можно рассматривать на отдельных уровнях работы, а не в куче в одном абзаце.
А для компенсации недостатков writeback cache еще пока никто не усложняет фс. Для этого делают battaried writeback cache. И не надо путать writeback cache в диске и в контроллере.
А фс усложняют для других случаев и еще раз - не надо все валить в кучу.
Ничего не имею сказать за fortran, близко не знаком.
Ну, это порядки работы гигабитного 2+ считча. Хотя с учетом остальной работы по фильтрации число хорошее.
С персоналом - это, думаю, так "повезло". Мне и freebsd-шные ортодоксы попадались.
С унификацией в линуксе - было бы желание. Практически любой дистр можно унифицировать под себя. Если система портов из freebsd ближе - на таком же принципе можно это сделать на гентушных оверлеях.
здрасти, а для чего вообще операционная система?
Свалили в одну кучу все - работу в юзерспейсе, sync и fsync, работу fs, которых много и все работают по-разному, а некоторые еще и внутри себя позволяют разные принципы работы с журналами, довалили i/o планировщики, которых тоже несколько и с разными политиками, и еще да, давайте довалим туда работу firmware контроллера, если он у нас есть.
Ага, зато всегда есть время написать на форуме, что пингвины - глючное поделие
Если бы мы спорили о ЯП, мне бы пришлось выслушивать аргументы о том, что php/perl/python/прочие языки с динамическим выделением памяти лучше си, там меньше шансов наступить на мину/острелить себе ногу.
Ну, все верно, и там, и там.
Про режим эксплуатации - ваш случай, полагаю, это все таки экстремальный режим эксплуатации.
На момент включения были цифры, по моему от 10% до 40% снижения нагрузки на cpu. Сейчас с ToE это уже, наверное, не актуально.
Та же история и в линуксе, но видите, тут, оказывается, некоторым в большинстве случаев системы на reiserfs ставят.
Понял, vpn lan-to-lan называется. Ну, openvpn - он в линуксе тоже успешно работает. Есть дистр такой zeroshell, он как раз под такие задачи заточен.
Хотелось бы услышать в пакетрейте в контексте конфигурации платформы, особенно на форварде интересно.
Без иронии - желаю подольше оставаться уверенным в этом. Себе желаю подольше быть уверенным в своем.
Вообще, мотив всего, чего я говорю (это предыдущим участникам ветки) - не стоит считать(особенно на основе голосований и всякой лирики), что линукс для пионеров, аfreebsd - для суровых мужчин. Это и есть самая настоящая пионерия.
Это просто анекдот
Вы это тоже из практики работы с MS-DOS'ом взяли? В юниксах этот момент куда сложнее.
Резюмируем попроще - я считаю, что достаточно просто sync'ить данные, когда есть в этом необходимость, сохраняя производительность. Вы, как я понял, хотите неотложенную запись в любом случае, то есть перенесли проблему из юзерспейса в кернелспейс. А не хотите еще для комплекта, чтобы ядро интеллектуально делало локировки файлов вместо прикладного программиста?
Это и называется - отстрелить себе ногу.
Про обширность документации на русском - надеюсь все таки, Вы авто не выбирали исходя из того, что в магазинах полно доков на русском, как чинить ВАЗ-ы.
А код открыт, куда уж больше документации.
да помилуйте, какая новизна?
Вам ли не знать, что бывает, когда не просто хочется, а просто необходимо выжать все возможное из платформы.
В линуксовом кернеле еще раньше появилась поддержка TSO для интеловских карт, года за 2-3 до поддержки TOE
>> как и у kqueue и epoll, что наводит на мысль тупого передиралова...
зато теперь приходится портировать epoll из линукса в freebsd заради всяких жав. :)
Все остальное, что вы описываете - ваши собственные ядерные наработки, так? Знаете, только по этой причине я не хочу с Вами спорить в этой ветке, просто по предположению, что Ваш выбор определен практикой, а не тем, что "на заборе написано".
Порядки чисел можете озвучить?
UPD. не денег, порядки HTTP high load
Не совсем понял про .1q на другой конец света? у вас общий layer2 с этим другим концом света?
Подозреваю, Вы это о L2TP. И чего? Для линукса VPN-ы недостижимое дело?
ng_fec использует кто? подскажите мне пожалуйста аналог ng_fec под линукс?
в линуксе это называется bonding
$kernel_src/Documentation/networking/bonding.txt
SLES это коробка, а не "ядро у пингвинов".
Во первых какого года этот текст? Посмотрите, когда вышел кернел 2.4.15, в котором появился ext3.
Во вторых - Вы еще начните для комплекта утверждать, что контроллеры без write back cache лучше, потому что без него меньше шансов потерять данные.
Вопрос о пионерии остается в силе. Теперь уже в контексте - линукс хуже, потому что там больше шансов отстрелить себе ногу.
