Представлен (http://www.dragonflybsd.org/release44/) релиз DragonFlyBSD 4.4 (http://www.dragonflybsd.org/), операционной системы с гибридным ядром, созданной (https://www.opennet.me/opennews/art.shtml?num=2717) в 2003 году с целью альтернативного развития ветки FreeBSD 4.x. Из особенностей DragonFly BSD можно выделить распределённую версионную файловую систему HAMMER (http://wiki.opennet.ru/HAMMER), поддержку загрузки "виртуальных" ядер системы как пользовательских процессов, возможность кэширования данных и мета-данных ФС на SSD-накопителях, учитывающие контекст вариантные символические ссылки, возможность заморозки процессов с сохранением их состояния на диске, гибридное ядро, использующее легковесные потоки (LWKT).Из наиболее существенных новшеств DragonFlyBSD 4.4 отмечается новая реализация локали, улучшение файловой системы Hammer, переход по умолчанию на новую систему динамического связывания и значительное обновление видеодрайверов i915 и Radeon.
Основные улучшения (http://www.dragonflybsd.org/release44/), добавленные в DragonFlyBSD 4.4:
- Существенное обновление drm-драйверов radeon и i915, используемых для переключения видеорежимов на уровня ядра для видеокарт AMD и Intel. Код драйверов i915 и radeon синхронизированы с ядром Linux 3.18. В i915 добавлена поддержка ValleyView, Baytrail и Cherryview Atom SOC, реализована полная поддержка аппаратного ускорения для GPU Broadwell, добавлена базовая поддержка APU на базе микроархитектуры Skylake, улучшены механизмы управления энергопотреблением. Системная консоль по умолчанию поддерживает работу через drm (KMS-консоль). Для карт Radeon добавлена поддержка датчиков температуры;
- Поддержка свойства локали LC_COLLATE (Collation (https://en.wikipedia.org/wiki/Collation)), позволяющая задавать правила сортировки и методы сопоставления с учётом смысла символов. При установке LC_COLLATE для указанной локали при сортировке и проверке диапазонов не будут разделяться строчные и прописные буквы (например, символы "A" и "a" войдут в диапазон [a-z], в то время как без LC_COLLATE в данный диапазон войдёт только "a"), при сортировке цифровых значений будет учитываться наличие минуса и точки перед числом и разные виды написания (1e3 = 1000), будут учитываться особенности языков (например, игнорироваться артикли, такие как The). Отмечается, что DragonFly BSD стала первой из BSD-систем с корректной поддержкой Collation для именованных локалей, что позволяет, например, использовать выражение COLLATE (http://www.postgresql.org/docs/devel/static/collation.html) в PostgreSQL. Поддержка Collation уже портирована из DragonFly BSD во FreeBSD-CURRENT;
- Полная переработка системы локали. До сих пор систем локали во DragonFly BSD синхронизировалась с FreeBSD, но в DragonFly BSD 4.4 реализация локали была полностью переработана. Данные для всех шести категорий локали (LC_CTYPE, LC_COLLATE, LC_TIME, LC_NUMERIC, LC_MONETARY, LC_MESSAGES) теперь основываются на актуальных выпусках Unicode CLDR (http://cldr.unicode.org/). Внесены улучшения в обработку чисел, времени и денежных единиц. Все определения CTYPE объединены в один набор сопоставлений. Добавлена поддержка трёхкомпонентных имён локалей, таких как sr_cyrl_RS, sr_latn_RS, zh_Hans_CN и zh_Hant_TW. Реализованные сокращённые коды локалей, например, "de_DE", "fr_FR" и "en_US" для 8-битовых кодировок.
- Системная библиотека регулярных выражений заменена на TRE (http://laurikari.net/tre/), что позволило избавиться от привязки к режиму POSIX (однобайтовые сопоставления) и реализовать полноценную поддержку многобайтовых кодировок в регулярных выражениях. Кроме поддержки многобайтовых кодировок библиотека TRE, которая уже используется в musl и OS X, обладает более высокой производительностью и поддерживает больший спектр регулярных выражений.
- Cистема динамического связывания переведена по умолчанию на компоновщик Gold (https://sourceware.org/viewvc/src/gold/README?revision=HEAD), разработанный инженерами Google и входящий в состав GNU binutils. Старый компоновщик "ld.bfd" доступен в качестве опции и может быть активирован в make.conf;
- В ядре улучшена поддержка возможностей CPU по экономии энергии. Добавлен системный вызов lwp_setname(2). Добавлен драйвер aperf(4) для вывода эффективной частоты CPU;- Улучшение сетевых возможностей:
- Добавлен драйвер iwm(4), в драйвер re(4) добавлена поддержка чипов Realtek 8168H.
- Добавлена утилита rtadvctl.
- Реализована асинхронная обработка UDP-соединений.
- Увеличен размер начального окна для TCP.
- Добавлена возможность изменения размера nmbcluster на лету.
- Код IPv6 синхронизирован с FreeBSD.
- Увеличена производительность вызова socket(2) для TCP и UDP.
- Добавлен системный вызов accept(4).
- Добавлена поддержка флагов SOCK_CLOEXEC и SOCK_NONBLOCK для вызовов socket(2) и accept4(2);- Библиотека libm заменена на вариант от проекта OpenBSD;
URL: http://www.dragonflybsd.org/release44/
Новость: http://www.opennet.me/opennews/art.shtml?num=43456
Чёт предыщая версия мне показалось очень глючной и тормозной, да ещё и порты с пакетами идут в неё автопортированием из FreeBSD. HAMMER даже не пробовал, на десктопах эта ФС точно не нужна.
Внушительный changelog, однако.
Одна из вещей, о развитии которых интереснее читать, нежели испытывать на практике.>Gold
как обычно, бегут впереди паравоза. Ещё недавно, добрая часть пакетов ломалась из-за него.
Прошлая моя попытка установить её на реальное железо потрепела крах. Когда мне удалось преодолеть все паники (с сожалением могу отметить, что выяснить из-за чего упс - тот ещё квест) оказалось, что с моей видеокартой о каком-либо ускорении можно забыть. Не прижилась.
> Ещё недавно, добрая часть пакетов ломалась из-за него.Это время прошло пять лет назад. Вот ведь время летит, а!
Ещё скажите регрессий не бывает. Нет, это было не так давно, в этом году даже.
>оказалось, что с моей видеокартой о каком-либо ускорении можно забытьnVidia небось?
Вкратце опишу чем лучше HAMMER.Товарищи оступили от традиционного подхода "на диске всегда должен быть порядок" и по умолчанию все новые данные пишутся в лог, который растёт практически бесконечно. Это значительно ускоряет запись по сравнению с ZFS и другими фичастыми системами, а читаются метаданные из лога один раз если нужно при загрузке и хранятся в памяти - т.е. несмотря на то что на диске слегка мусор работает оно очень быстро.
Чистка диска запускается отдельно, отдельный процесс перестраивает индексы, дефрагментирует блоки и выщёлкивает лишние. Это например значит что если при определённой операции нужно менять дерево оно будет реально перестраиваться во время чистки, а в промежутках состояние будет храниться в старом дереве + память + если нужно читай лог. При чём перестраиваться и записываться в новом виде на диск оно будет один раз а не при каждом изменении. То же самое с дедапом - в текущем виде в каком он есть в ZFS запись каждого блока требует найти хеш этого блока в индексе, если нужно - загрузить индекс. В hammer память отедается процессом, который один раз грузит индекс с диска, ищет по нему все блоки которые нужно дедуплицировать и - освобождает за собой память. В ZFS дедап - головная боль, в HAMMER - мелочи жизни.
> Вкратце опишу чем лучше HAMMER.Очередная никому не нужная академическая поделка от *BSD-шников. Все продакшены на ZFS, ext4. На перспективу пилят ФС-ы из линукса, от btrfs до lustre, например, сейчас intel формирует команду по развитию Lustre. На этот HAMMER никто внимания не обращает.
Lustre ортогональна локальным файловым системам. Btrfs до сих пор не вышла на стадию промышленной эксплуатации. Ext4 - улучшенная технология прошлого века (до сих пор не имеет поддержки снапшотов и нежурналируемого Copy-on-Write, в отличие от такого "старья", как UFS2).
Такое старьё, как UFS2 - валится чаще чем работает. И недосинкивает данные. Я бы вообще стремался такое ФС называть. Ext4 - всё что надо от экстентных ФС, ибо не снэпшотная. Вылизана до идеала. ZFS - всё что надо от снэпшотных ФС.
>Такое старьё, как UFS2 -
>валится чаще чем работает.Коротко говоря, это пустой пи*ж.
Типичный пустой и неочёмный ответ бздуна.
Ни разу более чем 10 лет UFS2 не разваливалась, единичные случаи - по вине умирающего железа. UFS2 стабильна и надежна как паровоз.
Несколько раз падал бояздэшный сервак по причине сгнивания UFS-2, после установки линуха - ожил. Работает. Выключения питания уже не страшны.
Часто запарывались бояздэшные виртуалки после принудительного завершения, линуху пофиг.
> Несколько раз падал бояздэшный сервак по причине сгнивания UFS-2Не задумывались, в чём причина?
> после установки линуха - ожил. Работает. Выключения питания уже не страшны.
В линухе просто отключено плановое сканирование fsck ради быстрого старта. Как включите - узнаете много нового. ;)
> Часто запарывались бояздэшные виртуалки после принудительного завершения, линуху пофиг.
Пройдитесь, наконец, fsck по файловой системе линукса, а то будете всё время в счастливом неведении. ;)
btrfs сначала сделайте, а потом уже пишите, сколько слов было, что вот в линуксе будет отличная ФС и еще не могут допильть, а теперь и слышно btrfs не надо
Сделали. Используют.
И зфс, и бтрфс, и экст4. Всё это есть в линуксе. У меня, кстати бтрфс в продакшне, на ссд.
>У меня, кстати бтрфс в продакшне, на ссд.Примите мои соболезнования.
А почему, если всё работает? Не модно, или не по плану? Вон сегодня привычно хаять бтр, а проверить на практике фимоз не позволяет?
>> Вкратце опишу чем лучше HAMMER.
> Очередная никому не нужная академическая поделка от *BSD-шников. Все продакшены на ZFS,
> ext4. На перспективу пилят ФС-ы из линукса, от btrfs до lustre,
> например, сейчас intel формирует команду по развитию Lustre. На этот HAMMER
> никто внимания не обращает.при профите в сотни процентов по скорости(сотни процентов, Карл !!)в хай-лоаде, а то и больше - очень даже нужная.
если "не нужная", значит просто "не умеете ее готовить".
> в хай-лоаде, а то и больше - очень даже нужная.Когда хоть на одном хай-лоадe, или даже не хай-лоаде, эта ФС появится, тогда и можно будет пальцы веером, а пока что это не более чем наколеночная поделка. Точно такие же поделки любой желающий может пилить себе, тихо сам с собою, сколько угодно, но никому кроме него они интересны не будут. Для хобби можно пилить что-то подобное сколько угодно, но для работы нужно изучать используемые и распространённые вещи, и работать именно с ними, чтоб без этой самой работы не остаться, сказанное справедливо и для разрабов и для админов. В противном случае получается обыкновенная *BSD-шная Masturbating monkeys.
> если "не нужная", значит просто "не умеете ее готовить".
Всё мы умеем готовить, вот только если на блюдо спроса нет, то и блюдо это нафиг никуда не впёрлось чтоб на него время тратить.
"наколеночная поделка" это ваши линуксы bloated неконсистентные и багуче-падучие.
а стеркоза - няшная, шустрая и управляемая. в отличие от.
> "наколеночная поделка" это ваши линуксы bloated неконсистентные и багуче-падучие.Ага и они такие богучие и падучие пашут в системах вроде Exadata и IBM-овских майнфреймов, и на всех без исключения прудукшен кластерах, насчитывающих тысячи и десятки тысяч нод, этим качественно отличающихся от всех известных на данный момент кластеров на *BSD, все из которых того же типа и категории, что и куча старого хлама в подвале у Тео. А система вроде Exadata-ы или майнфрейма на *BSD-это вообще невидаль абсолютная. Короче, желаю бздишникам кончать фанатеть и взглянуть на реальность.
> а стеркоза - няшная, шустрая и управляемая. в отличие от.У школьника на локалхосте она шустрая и няшная, потому что нигде больше она никем не применяется и не используется, и не случайно ведь, нет дураков связываться c сомнительными поделиями от masturbating monkeys.
> Короче, желаю бздишникам кончать фанатеть и взглянуть на реальность.- Заканчиваем, пацаны. Расходимся по домам. Они победили - нас переплюнула сама IBM! Линукс повсюду всё захавал, и это совершенная система, абсолютно безглючная. Нам нечего противопоставить. Наша карта бита... Эх! Пойду повешусь что ли... :))
>BSD 4.4У меня от этого UNIX
А у меня симптомы DARWIN
>>BSD 4.4
> У меня от этого UNIXвообще-то оно начиналось как форки фряхи, одним из ее старейших создателей ;)
Вариантные символические ссылки... я думаю это плохая придумка.
С видео конечно круто звучит, надо будет попробовать."Реализована асинхронная обработка UDP-соединений."
- что за бред?"Увеличен размер начального окна для TCP"
- он много от чего зависит, но можно было просто sysctl крутилку сделать."Добавлен системный вызов accept(4)"
"Добавлена поддержка флагов SOCK_CLOEXEC и SOCK_NONBLOCK"
- не прошло и пяти лет!Итого: хороший PR, хорошая расстановка приоритетов по фичам, но видимо мало людей.
> - что за бред?
> - он много от чего зависит, но можно было просто sysctl крутилку сделать.Итого: Напиши эти вопросы в мыллист DFLYBSD, какой смысл от твоих вопросов тут?
a почему Hammer2 не прижился во freebsd, а те тянут левую zfs?
https://wiki.freebsd.org/PortingHAMMERFS
Потому что это не пингвин? Бюджет той же мозиллы примерно раз в пятьсот (а в "неурожайные годы" и в тысячу) превышает бюджет фри.Хотя то, что все кому не лень, могут добавить свой индусо-корпоративный код в ядро пингвина, оному еще хорошенько аукнется:
https://github.com/torvalds/linux/commit/13b5be56d1c5ed302df...
>x86: hyperv: Fix brown paperbag typos reported by Fenguangs build robothttps://github.com/torvalds/linux/commit/76d388cd72ab08c2c56...
> x86: hyperv: Fixup the (brain) damage caused by the irq cleanup
> a почему Hammer2 не прижился во freebsd, а те тянут левую zfs?по тем-же причинам, по которым в линухе не прижился - не на что им там опереться, слабоваты, ос-и. ни lwkt, ни остального(а там ВАГОН принцпиально иного "под капотом").
>> a почему Hammer2 не прижился во freebsd, а те тянут левую zfs?
> что им там опереться, слабоваты, ос-и. ни lwkt,Этот срекозловый LWKT есть повторение и велосипед того, что с древности присутствует в solaris, хочешь платной, хочешь бесплатной, ничего принципиально нового с этим в стрекозе нет, кроме понтов. Но тут как раз стоит упомянуть про постоянно повторяемое теми, кто в теме, что zfs использовать нужно на родном, соляровом ядре, и никакая freebsd её полноценно не потянет, по причине неподходящей архитектуры упомянутых подсистем ядра.
> Этот срекозловый LWKT есть повторение и велосипед того, что с древности
> присутствует в solaris, хочешь платной, хочешь бесплатной, ничего принципиально нового
> с этим в стрекозе нет, кроме понтов.И как же называется в solaris аналог?
>>> a почему Hammer2 не прижился во freebsd, а те тянут левую zfs?
>> что им там опереться, слабоваты, ос-и. ни lwkt,
> Этот срекозловый LWKT есть повторение и велосипед того, что с древности
> присутствует в solaris, хочешь платной, хочешь бесплатной, ничего принципиально нового
> с этим в стрекозе нет, кроме понтов. Но тут как раз
> стоит упомянуть про постоянно повторяемое теми, кто в теме, что zfs
> использовать нужно на родном, соляровом ядре, и никакая freebsd её полноценно
> не потянет, по причине неподходящей архитектуры упомянутых подсистем ядра.ну во первых "велосипед" от санок - для другого написан и сравнивать его - все равно что обсуждать преимущества великаа перед параходом. не ровня стрекозе солярка и наоборот.
то-же про ... сан, из которых санк-овские продукты(не только ОС-и) состоят чуть менее, чем полностью, к сожалению(хотя во времена SunOS - все было еще хуже, конечно :).
> ну во первых "велосипед" от санок - для другого написанПонятно, что для другого, но общая суть та же-поток ядра как реальная единица планирования для шедулера исполнения в ядре. Эти kernel threads уже обслуживают с динамическим назначением все возможные абстракции исполнения, вроде потоков пользовательских процессов, прерываний, потоков, исполняющих задачи ядра, и пр. Такая схема обеспечивает лучшую масштабируемость, грубо говоря, всего что требуется. ZFS на уровне архитектуры своих отдельных подсистем (вроде zio) изначально ориентирована именно на эти существовавшие на то время особенности ядра соляриса. Поэтому копировать тупо zfs в другое ядро, как сделали доблестные фрибсдишники-это поведение толпы обезьян. В btrfs такого нет, там разработка с нуля изначально с привязкой к ядру линукса.
ЗЫ в z/OS те же принципы ещё со времён царя гороха.
А ничего, что LWKT - это примитив синхронизации, а не модель потоков в ядре?
> А ничего, что LWKT - это примитив синхронизации, а не модель потоков
> в ядре?ничего, ппотому что неправда.
это не "примитив синхронизации" , это названием исчерпывающе описанная фича ядра, ключевая(одна из).
и таки-да "модель потоков" - феерический костыль в ядре со времен C и unix-а, очень несекьюрный, плохо масштабирующийся итд итп. вообще всем кто юзает "потоки", "нити", "кучу"в 2015 году - надо поотрывать что-нить :/
Нет заинтересованных в портировании людей.
Потому что она еще в активной разработке? Сам Диллон говорит - пока только для тестеров, и то, кому невтерпеж уже. А первый хаммер пытались портировать и на фрю, и на линукс, но - студиозусы в рамках google summer of code. Nuff said, ога.
А портировать МОЛОТ в FreeBSD не пытались? Или не нужно?
выше отвечали уже
https://wiki.freebsd.org/PortingHAMMERFS
Полимеры нужна только автору драгона