FreeBSD on Niagara UltraSPARC T1

Недавно пришлось почитать список рассылки FreeBSD посвещенный
файловым системам и Linux:

в FreeBSD один топик в месяц:
блин хорошо бы сделать чтобы при обнаружение плохого блока на диске
система не паниковала и не вешалась, а КАК в Linux перемонтировала бы файловую систему в read-only.

в Linux:
-новая файловая система encryptfs - работающая поверх любой другой
-запись на UFS
-обсуждение что делать в случае если диск имеет объяем несколько терабайт и файловая система не предназначена для работы с таким диском
и многое многое другое.

и вопрос ну зачем дальше-то развивать эти *BSD или хотя бы объеденились с NetBSD.

А зачем развивать Linux ?

>А зачем развивать Linux ?

Потому что есть куча людей которым нужна хорошая открытая операционная система.

Конечно конкуреция это хорошо, но в случае с OpenSource все сводится
к передиранию хороших идей и распылению усилий и больше нечего.

Я думаю все бы выграли если бы не поритировали FreeBSD на UltraSparc а улучшили порт Linux или NetBSD.

В значительной мере команды *BSD занимаются исследовательской работой, в отличие от линакса с его передиранием фич из коммерческих юниксов.

"Типичный новый коммитер в проекте FreeBSD имеет возраст от 25 до 30 лет и програмиировал для Linux или других проектов с открытым исходным кодом в течении 10 лет".

Marshall Kirk McKusick в книге "The Design and Implementation of the FreeBSD Operating System".

> В значительной мере команды *BSD занимаются исследовательской работой, в отличие от линакса с его передиранием фич из коммерческих юниксов.

И что они там исследуют ? И где результаты ?

> "Типичный новый коммитер в проекте FreeBSD имеет возраст от 25 до 30 лет и програмиировал для Linux или других проектов с открытым исходным кодом в течении 10 лет".

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

// wbr

>> "Типичный новый коммитер в проекте FreeBSD имеет возраст от 25 до 30
>> лет и програмиировал для Linux или других проектов с открытым
>> исходным кодом в течении 10 лет".

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

.. и после того как результаты его творчества не пропускают злые дяденьки типа торвальдса что ему еще остается делать ?
правильно - валить на freebsd

:)

>В значительной мере команды *BSD занимаются исследовательской работой

Где? Нормальные файловые системы >2T, журналирование где? Как насчет хорошого маштабирования на несколько процессоров? Виртуализация?

Обсуждение а может добавим для mount user опцию КАК в Linux это исседования?

Вот DragonFly можно с натяжкой назвать иследованием, а о FreeBSD только накурившись травы можно такое сказать.

>"Типичный новый коммитер в проекте FreeBSD имеет возраст от 25 до 30 >лет и програмиировал для Linux или других проектов с открытым >исходным кодом в течении 10 лет".

Вернее его код не стали брать в Linux ядро и эти неудачники подались в FreeBSD.

>Marshall Kirk McKusick в книге "The Design and Implementation of the >FreeBSD Operating System".

Он тешит свое самолюбие.

>khm.. оч забавная фраза :)))

Maintainer 2.4 получил эту должность в 18 лет.

Ну например, эталонная реализация TCP/IP стека, доступная для любого желающего, или CARP в OpenBSD.

Читали дискуссию дальше?

Чувак попробовал на своей машине собрать это дело и пишет:

I ended up doing make -j8 buildworld because make -j32 exposed a panic
inducing race in NFS about 30 minutes in.

Отличная система что сказать.

>Ну например, эталонная реализация TCP/IP стека,
Свежо предание, может еще вспомним UFS?
Это было давно, сейчас это плетущийся в хвосте и ворующий
идеи кусок старины.

>доступная для любого желающего, или CARP в OpenBSD.

>Нормальные файловые системы >2T, журналирование где?

А при чем тут разработчики линакса? У них единственная Fs - это ext2/3 - а все остальное сделали стронние компании, типа IBM или SGI, то же самое можно сказать и про SMP, Numa и тд.

>А при чем тут разработчики линакса? У них единственная Fs - это >ext2/3 - а все остальное сделали стронние компании, типа IBM или >SGI, то же самое можно сказать и про SMP, Numa и тд.

Простите, определение "разработчиков" в студию.

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

И таким образом пасаж насчет это писали разработчики это нет мне непонятен.

Вообще-то так в линуксе все и делается,
человек/компания проводят изыскания,
присылают патч, он обсуждается, интегрируется,
и вносится соотвествующая запись в MAINTAINERS.

Таким образом люди из IBM, SGI также являются разработчиками как
и все остальные.

Там нету разделения ты из core team - тебе можно, а вам всем остальным нельзя как FreeBSD.

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

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

И что?
Знаешь самое забавное они есть, они открыты, не важно когда они были изобретены и для чего раньше предназначались для IRIX или OS/2.

Благодаря Linux они OpenSource. А FreeBSD пока ждет XFS как манны небесной.

reiser4 на подходе, это действительно огромная иследовательская работа в области построения ОС, проведенная кстати нашими соотечествиниками.

Никого не хочу обидеть, но FreeBSD сильно отстает в своем развитии от линукса. Это не камень в чей-то огород, а просто констатация реального положения дел.

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

а как насчет reiser, а ext3 это проекты предназначенные только для linux и аналогов в *BSD до сих пор нет.

Reiserfs v3.6 появился раньше ext3, работает в целом шустрее, та и стабильности достиг быстрее... не дампится конечно, но неужто только в силу сего сия ФС совсем уж некошерна? ;)
Для каждой задачи конечно свои исходные данные, но там глядишь скоро и 4-й рейзер отладят и ZFS нативно портируется... BSD?

А самое забавное, что если бы добрые дяди из SGI не отдали код, то не было бы в линаксе XFS, или если бы Sistina Software, Inc не протухла до состояния, что ее мог купить даже RH, то не было бы в линаксе LVM и Red Hat GFS сами юнные энтузазисты линукса таких вещей не осилили бы.

*BSD не ставят своей целью конкуренцию с кем нибудь. Меня просто веселят, заявления, что типа XFS которая развивалась более 10 лет и стоит тысячи человеко-лет разработчиков Irix - заслуга линакса.

>А самое забавное, что если бы добрые дяди из SGI

а если бы добрые дяди из AT&T не отдали код Unix Беркли не было
бы BSD, а если твоя мама не встретила бы твоего папы, то тебя бы не было. какой смысл твоего поста?

>А самое забавное, что если бы добрые дяди из SGI не отдали код

Вообще-то они посчитали что накладно поддерживать собственный Unix
и постепенно мигрировали на Linux, вопрос почему не на *BSD?

или например почему люди из Apple сначала встретились с Линусом
и предложили делать вместе ОС, и только после его отказа
стали работать с FreeBSD?

и почему в FreeBSD mailing lists все время Linux то, Linux се,
а в lkml раз в год, да и то...

>то типа XFS которая развивалась более 10 лет и стоит тысячи человеко->лет разработчиков Irix - заслуга линакса

если читать не умеешь то заслуга Linux, то что ее код открыт.

Тем не менее 'протухшие' компании отдали код в Linux а не в мегаправильную BSD с эталонным ip стеком. :-) Если тебе не дают бабы - то это в тебе проблема, а не в бабах. Саныч - уже не смешно, смени пластинку.

> Вообще-то они посчитали что накладно поддерживать собственный Unix и постепенно мигрировали на Linux, вопрос почему не на *BSD?

по причине уже существующего PRа + лицензия GPL?

// wbr

>по причине уже существующего PRа + лицензия GPL?

я думаю в те времена linux был не так известен,
скорее GPL и то что она хорошо работала на их машинках.

у них только EXT2. EXT3 делал RH для них..

ну что клафудра нашел man9 в linux или еще в процессе?

>у них только EXT2. EXT3 делал RH для них..

А RH это значит не разработчики? :)

Кто же разработчики? Один Линус ?

> я думаю в те времена linux был не так известен,

впрочем, как и BSD :)

> скорее GPL и то что она хорошо работала на их машинках.

ммм.. в смысле на машинках работала лицензия GPL или на них работал Linux тех времен?

// wbr

> ну что клафудра нашел man9 в linux или еще в процессе?

нет, к сожалению так и не нашел :(
то, что нашел, воспринимать как man весьма проблематично.

// wbr

>ммм.. в смысле на машинках работала лицензия GPL или на них работал >Linux тех времен?

а подумать? GPL стала архитектурно зависимой?

>нет, к сожалению так и не нашел :(

бедняга, переписывай свою fs для FreeBSD,
только не собирай с помощью make -j32, а то повиснет.

> бедняга, переписывай свою fs для FreeBSD,

зачем переписывать? BSD, Solaris, HPUX, AIX и WinNT/XP/2003 и так поддерживаются by default, равно как и Linux.

// wbr

>У них единственная Fs - это ext2/3

и ext3 уделывает фревую ufs в хвост и в гриву. непонятно чего ты кипятишься уссаныч, не тебя же уделывают. или ты свои комплексы на оси переносишь?

>Простите, определение "разработчиков" в студию.

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

>И таким образом пасаж насчет это писали разработчики это нет мне >непонятен.

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

Думаю если бы выбор пал на Фряху она тоже былабы сейчас достаточно развита.

> Вот DragonFly можно с натяжкой назвать иследованием

Без всякой натяжки.

> а порт в линаксе не поддерживает ее фичи в полном объеме до сих пор, хотя не уверен, может уже дотянули?

Sun-ch, ты в Linux работаешь, или просто поливаешь?

>то заслуга Linux, то что ее код открыт.

А велика ли заслуга? Что мы имеем в итоге? Недоношенный вариант, некогда легендарной fs? Причем лицензия не позволяет ее использовать в той же BSD или Windows, а сами линусоды чего то не спешат ее улутшать.

Конечно работаю, у меня слака, центос и крукс.

FreeBSD гораздо технологичнее чем Linux.
В Linux нет такой замечательной вещи как kqueue.
В Linux нет такой технологии как KSE.
Врядли найдется заменитель Netgraph.
Насчет файловых систем:
В Linux преодолен 1Tb порог размера файла?
Журналирование FS это не панацея, softupdates быстрее.
CAM канечно тормоз, но упрощает разработку, а в Linux?
И имхо самая страшная беда Linux: бардак и отсутсвие дисциплины.
( Положительная динамика в этом моменте наметилась лишь при внимании "тяжеловесов" )

>Причем лицензия не позволяет ее использовать в той же BSD или Windows

А драйвер nVidia в FreeBSD тоже лицензия не позволяет использовать? Для чего же этот драйвер существует?

А драйвер ext3 под виндой (GPL-ный) тоже нельзя использовать? Упс, а не знал и использовал...

>FreeBSD гораздо технологичнее чем Linux.

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

> Linux нет такой замечательной вещи как kqueue.

Есть epoll, есть AIO, есть сторонние разработки (на том же lwn.net несколько недель назад была статья про kevent со сравнением его с kqueue (последний, впрочем как и epoll, проиграл))

>В Linux нет такой технологии как KSE.

Все нормальные люди с диким ужасом смотрят на потоковые модели N:1. Почитайте, как solaris отказалась от N:1, если Linux не авторитет.

Впрочем, понятно, почему freebsd изобретает это, т.к. у них нет glibc?

>Врядли найдется заменитель Netgraph.

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

>Насчет файловых систем:

>В Linux преодолен 1Tb порог размера файла?

А он был? VFS поддерживает файлы любых размеров вплоть до 2^64-1

>Журналирование FS это не панацея, softupdates быстрее.

Да ну? Это вам МакКузик сказал или вы тесты произовдительности делали?

>CAM канечно тормоз, но упрощает разработку, а в Linux? >И имхо самая страшная беда Linux: бардак и отсутсвие дисциплины. ( Положительная динамика в этом моменте наметилась лишь при внимании "тяжеловесов" )

Blah-blah-blah...

>>> а порт в линаксе не поддерживает ее фичи в полном объеме до сих пор, хотя не уверен, может уже дотянули?

>>Sun-ch, ты в Linux работаешь, или просто поливаешь?

> Конечно работаю, у меня слака, центос и крукс.

И при этом ты не знаешь, поддерживает ли XFS "фичи в полном объеме" или нет? Сразу видно, как сильно они тебе нужны. Насколько я знаю, единственная фича, которую "недоношенный вариант, некогда легендарной fs" _не_ поддерживает, это guaranteed-rate IO (данные 2-3 лет давности). Наверное, это можно было бы реализовать на 2.6 с его новой инфраструктурой блочного ввода-вывода, но, видно, никому это не надо.

>Есть epoll, есть AIO, есть сторонние разработки (на том же lwn.net несколько недель назад была статья про kevent со сравнением его с kqueue (последний, впрочем как и epoll, проиграл))

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

>Все нормальные люди с диким ужасом смотрят на потоковые модели N:1. Почитайте, как solaris отказалась от N:1, если Linux не авторитет.

В Linux LWP почти по "тяжести" почти == обычному процессу, KSE же после выхода из состояния ЭКСПЕРИМЕНТА (Заметь!) позволит заметно уменьшить K<->U

>Впрочем, понятно, почему freebsd изобретает это, т.к. у них нет glibc?

FreeBSD и libc едины, что нельзя сказать о Linux и glibc

>А он был? VFS поддерживает файлы любых размеров вплоть до 2^64-1

можеть быть попробуете? ext2fs/ext3fs неасилит 100%

>Да ну? Это вам МакКузик сказал или вы тесты произовдительности делали?

речь о РЕАЛЬНОЙ альтернативе журналируемой FS

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

Да, kqueue вещь гибкая и удобная (но я сужу только по описаниям), жаль, что Линус против нее.

> В В Linux LWP почти по "тяжести" почти == обычному процессу,

Скажем так - в Linux нить по "тяжести" < обычного процесса, Значительную часть веса составляет стек режима ядра. Выигрыш BSD с KSE в этом плане - то, что стеков режима ядра нужно меньше. Насколько меньше - только реальная эксплуатация покажет. С учетом дешевой памяти, 64-бит систем и CONFIG_4KSTACKS, вряд ли BSD выиграет ощутимо. Время покажет. И время уже показало, что в реализации модель 1:1 гораздо проще (со всеми вытекающими).

> KSE же после выхода из состояния ЭКСПЕРИМЕНТА (Заметь!) позволит заметно уменьшить K<->U

Что такое "уменьшить K<->U" ? Для преключения контекста в KSE всё равно делается upcall (так это называется? ;) ) из ядра в userspace.

>>Есть epoll, есть AIO, есть сторонние разработки (на том же lwn.net несколько недель назад была статья про kevent со сравнением его с kqueue (последний, впрочем как и epoll, проиграл))

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

Что значит параллельно? В kqueue одна очередь, из которой последовательно забираются события.

>>Все нормальные люди с диким ужасом смотрят на потоковые модели N:1. Почитайте, как solaris отказалась от N:1, если Linux не авторитет.

>В Linux LWP почти по "тяжести" почти == обычному процессу, KSE же после выхода из состояния ЭКСПЕРИМЕНТА (Заметь!) позволит заметно уменьшить K<->U

Вы неправильно сделали акцент - в Linux создание обычного процесса лишь слегка более накладная операция, чем создание thread (или lwp, хотя этот термин, imho, не употребляется уже).

Это _очень_ быстрая операция, если во freebsd смогут добиться такого же результата, это будет очень здорово. Но похоже, что добиться этого freebsd сможет только используя userspace pools, что ведет к очень серьезным неприятностям...

>>Впрочем, понятно, почему freebsd изобретает это, т.к. у них нет glibc?

>FreeBSD и libc едины, что нельзя сказать о Linux и glibc

Да не нервничайте вы так, я всего лишь говорил, что freebsd libc не имеет тех возможностей, которые есть в glibc.

>>А он был? VFS поддерживает файлы любых размеров вплоть до 2^64-1

>можеть быть попробуете? ext2fs/ext3fs неасилит 100%

Т.е. вы сказали это наугад, может быть найдеся в Linux FS, в которой размеры передаются в u32...

В ext3 размер файла до 1Тб, вся файловая система на 32битном CPU - до 4 тб.

В reiser 2.6 максимальный размер файла - 8тб на 32битном cpu.

>>Да ну? Это вам МакКузик сказал или вы тесты произовдительности делали?

>речь о РЕАЛЬНОЙ альтернативе журналируемой FS

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

>В reiser 2.6 максимальный размер файла - 8тб на 32битном cpu.

reiser 3.6

>>А он был? VFS поддерживает файлы любых размеров вплоть до 2^64-1

> можеть быть попробуете? ext2fs/ext3fs неасилит 100%

пробовать не стану - на диске места не хватит :). Но вообще-то в Linux много ФС. XFS, JFS - должны справится.

Квоты на директории прикрутили уже? А что насчет XLV Volume Manager?