The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз ядра Linux 6.7, opennews (?), 08-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


73. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 08-Янв-24, 15:23 
> Если там не раздутый бегемот как Btrfs и не окаменевшее ископаемое как
> ZFS то можно даже попробовать на чем-то некритичном.

Сделан "по мотивам" btrfs - но с прицелом на шустрые сторажи и потому минимальный оверхед, а еще там иерархиеческое кеширование на уровне выбора девайсов и куда записывать. Так то прикольно придумано.

Но багов пока есть, для прода пожалуй рановато. За время -rc раза 3 фиксы были т.к. довольно заметные проблемы вылезли при тесте толпой на майнлайне.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

76. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (34), 08-Янв-24, 15:26 
Для энтерпрайзного прода - рановато, а вот накатить на десктоп (у вас же бэкапы есть?) - вполне можно.
Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз ядра Linux 6.7"  +1 +/
Сообщение от Аноним (-), 08-Янв-24, 15:36 
> Для энтерпрайзного прода - рановато, а вот накатить на десктоп
> (у вас же бэкапы есть?) - вполне можно.

Я на десктопе работы работаю. И если ФС взбрыкнет а мне проект надо было доделать - это не айс. Вы не боитесь, я это добро потестил на VM. И таки огреб эн багов, показал причастным - половины уже нет.

В целом оно в принципе юзабельно. Но...
1) Разработчики btrfs времени зря не теряли и с всеми их оптимизациями - bcachefs никаких особых революций в перфомансе не показывает, по сравнению с ними. Как минимум - пока. Впрочем сейчас вопрос о том чтобы оно вообще работало без косяков - а оптимизациям свое время. И вот тогда поговорим об этом.
2) Некоторые фичи все же откровенно WIP. Или совсем не запилены. В частности parity/reedsolomon, и еще ряд.

Но кенту всяческие респекты за упертость. Теперь в ядре две продвинутых CoW и это хорошо, некий выбор, небольшая конкуренция между тимами и проч совсе не вредно :)

Ответить | Правка | Наверх | Cообщить модератору

92. "Релиз ядра Linux 6.7"  –1 +/
Сообщение от Аноним (34), 08-Янв-24, 15:54 
>Я на десктопе работы работаю. И если ФС взбрыкнет а мне проект надо было доделать - это не айс. Вы не боитесь, я это добро потестил на VM. И таки огреб эн багов, показал причастным - половины уже нет.

Ну я тоже работы работаю, только у меня елси ФС взбрыкнет - я просто пересяду за другую машину... Так что мне как-то похрен. Работу работаю - это энтерпрайзный прод, всё же. Под десктопом я имею ввиду всё же не рабочую станцию, а приспособу для маловажных вещей для дома - кинчик посмотреть, в игрушку поиграть, в интернетиках посидеть.

А про баги это правильно, я баги в amdgpu показывал, их вроде все успели вынести до релиза.

>bcachefs никаких особых революций в перфомансе не показывает,

Да и с чего бы их показывать, на самом деле? Киллерфича - это бутербродная компоновка девайсов - сиречь кэш. Вот, например, я захотел в танки поиграть на выходных - и первая загрузка с харда - мееедленная. Зато последующие - быстрые, пока мне танки не надоедят и я не переключусь на другую игрулю. writeback кэш - тоже ооочень приятно (у меня основным хранилищем тормозной SMR).

>Некоторые фичи все же откровенно WIP. Или совсем не запилены. В частности parity/reedsolomon, и еще ряд

Я там выше писал, в общем-то. Согласен полностью, тут дело даже не только в фичах, а есть мелкие огрехи в утилитах. Так что оно явно не заменяет собой ни btrfs ни zfs во всех юзкейсах. А вот кое-где оно уже всех уделало, теперь bcache не нужен (он имеет проблемы с саспендом/гибернацией).

>Но кенту всяческие респекты за упертость.

Это таки да. Если бы не гребаная политика - задонатил бы.

Ответить | Правка | Наверх | Cообщить модератору

125. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 08-Янв-24, 17:35 
> Ну я тоже работы работаю, только у меня елси ФС взбрыкнет -
> я просто пересяду за другую машину...

Это как минимум перенос проекта и сетап рабочего окружения заново. Не то чтобы велкам. А затестить можно и на виртуалке, коих у меня есть. Они для этого удобны :)

> Так что мне как-то похрен. Работу работаю - это энтерпрайзный прод, всё же.

А у меня - режим сам себе режиссера. Впрочем у меня есть пара "запасных" компов и ноут, но вообще-то агрессивное маневрирование на "primary" воркстейшне не логично. Он как раз "продакшн", а воооон те компы как раз чтобы можно было системные эксперименты ставить даже если все развалится нахрен. Но виртуалки чинить и сетапить проще :)

> вещей для дома - кинчик посмотреть, в игрушку поиграть, в интернетиках посидеть.

У меня ситуация несколько иная.

> А про баги это правильно, я баги в amdgpu показывал, их вроде
> все успели вынести до релиза.

Во! Это правильный подход к делу. Эй, ташкинов и прочие freehck, учитесь как надо было!

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

Вообще кентушка заморочился low overhead. Правда с тех пор и btrfs'ники - заморочились :)

> и я не переключусь на другую игрулю. writeback кэш - тоже
> ооочень приятно (у меня основным хранилищем тормозной SMR).

Ну я как бы согласен что фича - весьма годная. Я до нее со временем доберусь имхо :)

> только в фичах, а есть мелкие огрехи в утилитах.

И не очень мелкие тоже. Скажем FUSE реализация - вообще труп по сути. Они конечно честно пишут что экспериментальная. Но это экспериментальное в экспериментальном. Впрочем без этого можно жить.

> юзкейсах. А вот кое-где оно уже всех уделало, теперь bcache не
> нужен (он имеет проблемы с саспендом/гибернацией).

ИМХО главная его проблема - когда SSD на который оно кешило затирается, это имеет тенденцию гробить подкешированую ФС наповал. Блочный уровень слишком дубов и туп чтобы на это норм рагировать. ФС же будет видеть какие реплики нагнулись и если избыточность есть, сможет маневрировать куда разумнее.

>>Но кенту всяческие респекты за упертость.
> Это таки да. Если бы не гребаная политика - задонатил бы.

Есть более 9000 способов помочь гражданину не деньгами так борзыми щенками. Даже вот отловить косяки - тоже способ сказать спасибо. Файлуха в целом улучшится, станет более привлекательной, на нее быстрее подсядет кто-то крупный, кто денег насыпет.

Ответить | Правка | Наверх | Cообщить модератору

145. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (34), 08-Янв-24, 18:16 
>Это как минимум перенос проекта и сетап рабочего окружения заново. Не то чтобы велкам.

Я не знаю, с чем вы работаете и какие у вас сроки поднятия из бэкапа. Мне нужно убдет отойти на 10-15 минут и я потеряю максимум час работы. Не смертельно, но неприятно. Ну и я не пользуюсь всякими хитрыми фичами. Т.е. вероятность проблем - приемлемая для меня ).

>Вообще кентушка заморочился low overhead. Правда с тех пор и btrfs'ники - заморочились :)

Да все равно мы упираемся в сырую производительность носителей... Тут уже никуда не денешься, CoW - значит фрагментация, больше оверхеда и т.п. Понятное дело, что чем больше фич, тем медленнее - вон, fat12 так вообще шустрый был... Да, то, что он заморачивается - это хорошо, конечно.

>Скажем FUSE реализация - вообще труп по сути.

Не тыкал, не знаю, мне не нужно, я в этом конкретно вопросе не копенгаген, могу говорить только за то, что трогал :)

>когда SSD на который оно кешило затирается, это имеет тенденцию гробить подкешированую ФС наповал.

Падажжи. Если SSD затирается - он уходит в RO, либо отваливается совсем, либо не отдает прочитанные данные, так как чексуммы не совпадают и ECC не может уже их поднять у диска. А перед этим начинает сыпать в смарте проблемами... Т.е. в нормальном случае носитель должен быть заменен до того, как начнет отдавать мусор вместо данных. А вот если у нас writeback кэш и, как у меня, скажем, метаданные лежат ТОЛЬКО на SSD - то как он у меня умрет - умрут вместе с этим SSD и все данные, что лежат в background hdd. Тут все от сетапа зависит. Но если я увижу ошибки в smart (а я его контролирую) - возможно, я успею выставить durability=0 носителю и он превратится в writethrough и я спокойно смогу дожить до магазина ;).

>Даже вот отловить косяки - тоже способ сказать спасибо.

Чем и занимался, так-то. Просто при моем сетапе косяков не возникло а те, что есть - складируются и потом либо буду багрепортить, либо сам поправлю (хочу сам, например, баг со временем поправить).

Ответить | Правка | Наверх | Cообщить модератору

338. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 09-Янв-24, 20:41 
> Я не знаю, с чем вы работаете и какие у вас сроки поднятия из бэкапа.

Я тоже не знаю - ибо не требовалось, как максимум откат снапшота за пару минут. Странно взять звездолет с гипердрайвом и машиной времени и не попрыгать по мультивселенным с альтернативными реальностями. Да, это нелинейный менеджмент системы. Можно хоть эн параллельных веток эволюции отращивать. Или - send этого в VM -> receive -> о, мой десктоп теперь в VM где я и болтаю с вами. С снапшотами почти нет отличия между VM и bare metal...

> Мне нужно убдет отойти на 10-15 минут и я потеряю максимум час работы.
> Не смертельно, но неприятно. Ну и я не пользуюсь всякими хитрыми фичами.
> Т.е. вероятность проблем - приемлемая для меня ).

Я вот именно бэкапы делаю реже и на физически отключаемый винч, так что он переживет полный rm -rf, runaway dd в блочный девайс, или что там еще. А снапшот - скажем перед крупным апгрейдом системы и ключевого софта. Если не понравится, верну за 2 минуты как было "1 в 1". При том могу старый state оставить для изучения, в отличие от бэкапов. Мультивселенная!

> Да все равно мы упираемся в сырую производительность носителей...

В энтерпрайзных SSD - уже и в кишки ядра бывает. Потому и рефакторы типа folios, io_uring, вот это все. И для ФС рефакторы и редизайны тоже так то логичны.

> Тут уже никуда не денешься, CoW - значит фрагментация, больше оверхеда и т.п.

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

Оверхед возможен на блоках с эн референсами, e.g. снапшотах, рефлинках, ... и у btrfs и bcachefs есть особенности, они несколько разные из за разного дизайна. Их актуально знать при активном использовании снапшотов. Это как с VM - там тоже ряд концепций в CoW дисках стоит понимать, не отращивая очень большие дельты или их разлапистые иерархии.

> дело, что чем больше фич, тем медленнее - вон, fat12 так
> вообще шустрый был...

У него индексов нет, с большими иерархиями FAT тормоз! И алокация педальная, эктентов там IIRC нет. Так что современные ФС его могут легко сделать. Боолее того - билд кернела ворочает около 250К файлов. И это не напрягает. Даже на btrfs. На FAT - удачи! Вы и на NTFS то это взвоете, там в разы тормознее все. А при 100К файлов в 1 дире в ntfs наступает апокалиптец, чтения диры дождаться малореально вообще.

> Да, то, что он заморачивается - это хорошо, конечно.

У него неплохое мышление. Мне не нравится его хайп с растом, хотя-бы из соображений build deps, но оно в данный момент там опционально.

>>Скажем FUSE реализация - вообще труп по сути.
> Не тыкал, не знаю, мне не нужно,

Убер-глючное на данный момент. Я бы мог найти пару сценариев где это имеет смысл, но для меня это low priority экспериментальная хрень, я сильно на вот это - не дергался.

> Падажжи. Если SSD затирается - он уходит в RO, либо отваливается совсем,

Щаззз! Есть еще минимум 1 режим отказов! Падлюка в меру дурости начинает выгружать порушеные данные, IO error не репортит - и нате вам шум океанов марса (видимо после неуспешного декодирования FEC). У меня даже такая флеха есть, но ЭТО замечено и для энтерпрайзных SSD под bcache, файлухи разумеется очень плохо на такие подарки реагируют и при игноре этого - осыпаются к хренам и зачастую наповал. Btrfs'ник с энтерпрайзным SSD попал под внимание потому что удивлялся:
- А это не баг в ФС? Орет постоянно CSUM FAILED?!
- А что за конфиг?
- Блаблабла, энтерпрайзный SSD, bcache, ...
- Не, чувак, это не баг в ФС! Срочно замени свой SSD под кешом! Иначе у тебя подохнет все и совсем.

Я потом видел еще несколкько случаев ЭТОГО в более жесткой форме, юзеры ext4 и xfs такое обычно замечают слишком поздно, когда оно - уже совсем хренакс. Чексумы по всей площади способствуют отлову ЭТОГО до того как оно приобретет совсем злой масштаб.

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

Или, как оказалось - отдает, левак какой-то. Btrfs в этом случае радостно орет на левые чексумы, чем хайлайтит полезность таковых лишний раз. У меня со временем даже такая флеха вот была отловлена и теперь у меня есть "reproducer", хоть и не энтерпрайзный, но поведение то же самое.

> А перед этим начинает сыпать в смарте проблемами...

Смарт рулится фирмварью и потому - его полезность и реалистичность весьма варьируется.

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

Как показали господа "в интерьере" это обычно скорее так:
- А чойта за баг в btrfs - csum failed?!
- Упс, а чойта мой ext4 развалился и совсем не маунтится? Был на bcache...

Несколько вот таких succes story навели тех кто интересовался вопросом на понимание определенного паттерна.

> умрет - умрут вместе с этим SSD и все данные, что
> лежат в background hdd.

Ну вот когда ФС кешируется bcache и SSD делает вон то, разлет получается хорош.

> я успею выставить durability=0 носителю и он превратится в writethrough и
> я спокойно смогу дожить до магазина ;).

КМК лучше хотеть durability == 2 (RAID1) для как минмум метаданных, а лучше и данных, если они ценные. И кстати EPIC WIN на эту тему что у кента что у btrfs мог бы быть если бы это можно было по файлам/дирам/subvol конфигурить, при том я готов поспорить что аллокатор сам по себе мог бы это обеспечить, просто конфигурационного интерфейса для такого нет. А желательно еще и устаканившегося и одинакового для ФС которые так умеют (с точки зрения настройки из юзермода). Next-gen дизайнам на самом деле душно с чистым POSIX.

>>Даже вот отловить косяки - тоже способ сказать спасибо.
> Чем и занимался, так-то. Просто при моем сетапе косяков не возникло а
> те, что есть - складируются и потом либо буду багрепортить, либо
> сам поправлю (хочу сам, например, баг со временем поправить).

Весьма похвальный подход к делу :). Вот все бы так. Учитесь ташкиновы и freehck как на самом деле надо было :P.

Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз ядра Linux 6.7"  +/
Сообщение от DEF (?), 08-Янв-24, 15:53 
К следующему LTS.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру