The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

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

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


3. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (3), 08-Янв-24, 10:41 
Если там не раздутый бегемот как Btrfs и не окаменевшее ископаемое как ZFS то можно даже попробовать на чем-то некритичном.
Ответить | Правка | Наверх | Cообщить модератору

5. "Релиз ядра Linux 6.7"  –5 +/–
Сообщение от Аноним (5), 08-Янв-24, 11:11 
Не вижу проблем применения ни btrfs ни с ZFS. Продакшен же давно
Ответить | Правка | Наверх | Cообщить модератору

9. "Релиз ядра Linux 6.7"  +5 +/–
Сообщение от Аноним (9), 08-Янв-24, 11:37 
Продакш не спасает от потери данных.
Ответить | Правка | Наверх | Cообщить модератору

162. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (154), 08-Янв-24, 18:32 
В продакшене данные, которые жалко потерять, хранят в специальных СУБД с распределёнными избыточным хранением и бэкапами. А утеря хоста вообще ничем особенным не является, хост просто выкидывается и переподнимается где-нибудь ещё
Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (3), 08-Янв-24, 12:40 
Вопрос не в применении, вопрос в эргономичности. В BTRFS даже точное свободное место нельзя посмотреть без костылей.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

34. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (34), 08-Янв-24, 13:17 
Сижу на этом с 6.7-rc1 и впечатления пока что только положительные. Есть минусы, но по сравнению с btrfs и zfs они просто ничтожны.
Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз ядра Linux 6.7"  +/–
Сообщение от оно ним (?), 08-Янв-24, 13:49 
Что за минусы-то, хоть бы рассказал.
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз ядра Linux 6.7"  +5 +/–
Сообщение от Аноним (34), 08-Янв-24, 15:12 
Сетап - для хомяка ноутбучный SMR на терабайт, в качестве кэша - Kingston UV400 га 240 гигабайт. Сжатие - lz4 в бэкграунде. Ну т.е. ссд в качестве writeback кэша, во время ребаланса происходит сжатие данных и запись на бэкграунд HDD. Минусы - то, что тулзы местами недоделанные. Например, если смотреть rebalance status - то нихрена непонятно, сколько ему еще ребалансить. Нельзя вызвать ребаланс самому или изменить триггеры, вызывающие ребаланс. Это не мешает, но я хочу, например, делать ребаланс чаще. Так же, например, изменение таргета для метаданных не заставляет при очередном ребалансе метаданные переносить с носителя на выбранный полностью, приходится лапками мув данных запускать. Мелочи, в общем. RAID5/6 использовать не рекомендуется пока, насколько я понял, а так же _нельзя_ использовать erasure coding - ибо нестабильно. А вымораживает меня то, что оно не дает винту стопнуть шпиндель - раз в секунду что-то читается, или журналы сбрасываются. Я пока не понял, можно ли журнал убрать с HDD. Жить не мешает, но т.к. все нужные данные обычно в кэше (там обычный LRU) - мне хочется, чтобы хард стопался через минут так 5 неактивности, а вот хрен то там. Подозреваю, в следующих релизах поправят. Если погуглить - есть жалобы на nocow - мол, корраптит файлы - вот это жирный косяк, но вроде по последним коммитам что-то в этом направлении было сделано в rc7). Есть жалобы, что девайс не всегда получается вывести из массива, но тут я не тестил - и, в общем, понятно, что это будет исправляться - вроде как в linux-next там на эту тему тоже что-то заброшено. Есть косяк, что если смотреть rebalance_status из sysfs - оно IO считает в каких-то странных единицах, ошибка в выводе времени отображения ожидания ребаланса (200 секунд отображаются как 200 минут, а 3600 секунд - как 3600 часов) - но, я так понимаю, Кенту на это начхать пока что, да оно и не важно.

Пережило с десяток отключений питания, нормально работает в гибернации (я использую для хомяка, корень у меня на другом SSD). Восстановление после сбоя бывает длительным, но пока ничего не потерялось.

Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd висла, поэтому на корень я бы это тоже ставить не стал.

Почему оно лучше чем btrfs - так это я свободное место могу нормально видеть, там зарезервировано, кстати, в дефолте 8%. Собственно, сжатие тоже как-то странную статистику показывает, но то, что у меня на 200 гиг раздел свободнее чем планировалось - таки да.

uncompressed:
        nr extents:             3684626
        size:                   507 GiB
compressed:
        nr extents:             3724187
        compressed size:        216 GiB
        uncompressed size:      448 GiB
incompressible:
        nr extents:             10889179
        size:                   622 GiB

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

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

102. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (-), 08-Янв-24, 16:29 
> Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd
> висла, поэтому на корень я бы это тоже ставить не стал.

Вероятно дело в том что большая часть тулсов/либ в вашей системе еще не знает этот тип ФС. Оно также не маунтится mount'ом без явного указания -t bcachefs, автодетект не срабатывает.

Но в виртуалке на рутфс - пашет. Даже с системдой. В этом случае в командлайне ядра тип ФС стоит указывать. Т.е. как-то типа root=/dev/vdb rootfstype=bcachefs (это часть командлайна ядра).

> Почему оно лучше чем btrfs - так это я свободное место могу
> нормально видеть, там зарезервировано, кстати, в дефолте 8%.

1) Уже убрали вроде этот резерв как слишком радикальный...
2) В силу специфики ФС оно тоже может видеть свободное место несколько специфично. Это обратная сторона медали продвинутой аллокации, фич типа сжатия/многодисковых схем/etc.

> Собственно, сжатие тоже как-то странную статистику показывает, но то, что у меня на 200
> гиг раздел свободнее чем планировалось - таки да.

Да вообще оно работает. Вон на виртуалках чартерными рейсами пашет. Но некие аномалии все же вылезли.

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

Люди делятся на 2 типа - те кто еще не делает бэкапы и те кто уже делает.

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

104. "Релиз ядра Linux 6.7"  +/–
Сообщение от Qq (?), 08-Янв-24, 16:33 
> Люди делятся на 2 типа - те кто еще не делает бэкапы и те кто уже делает.

3, есть те кто проверяет целостность бекапов

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

106. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 16:36 
> 3, есть те кто проверяет целостность бекапов

Теперь еще расскажите как вы это делаете для всех файлов бэкапа, что там реально то что должно быть и вас никто не подвел... :)

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

118. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (34), 08-Янв-24, 17:11 
Целостность бэкапов это не проверка файлов в них. Это проверка того, что архивы могут быть распакованы. А проверка файлов делается, внезапно, восстановлением из бэкапа и сверкой атрибутов файлов и их хеш-сумм.
Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 17:37 
> Целостность бэкапов это не проверка файлов в них. Это проверка того, что
> архивы могут быть распакованы. А проверка файлов делается, внезапно, восстановлением из
> бэкапа и сверкой атрибутов файлов и их хеш-сумм.

Самое интересное что все это никак не гарантирует что та БД работает, фоточка открывается, видео играется, ... :)

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

156. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 18:26 
Не гарантирует. Но вероятность составляет ~1*10^-400. Насколько это мало - можешь сам представить.
Ответить | Правка | Наверх | Cообщить модератору

257. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 09-Янв-24, 00:58 
> Не гарантирует. Но вероятность составляет ~1*10^-400. Насколько это мало - можешь сам
> представить.

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

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

111. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (34), 08-Янв-24, 16:44 
>большая часть тулсов/либ в вашей системе еще не знает этот тип ФС.

Manjaro unstable? bcachefs-tools из aur? Сомневаюсь ).
>не маунтится mount'ом без явного указания -t bcachefs, автодетект не срабатывает.

Это правда. Но оно не маунтилось у меня при задании сего действа в fstab (начинал с одного диска).
>В этом случае в командлайне ядра тип ФС стоит указывать.

Ну у меня оно поверх luks, так что, может, я с коммандлайном ядра обгадился. Возможно. Родное шифрование я там тыкать пока что не захотел, смигрирую потом когда-нибудь.
>1) Уже убрали вроде этот резерв как слишком радикальный...

Можно на лету поменять, это резерв для GC. Может и убрали, но у меня создана ФС была, когда он еще был. Мне не мешает.
> оно тоже может видеть свободное место несколько специфично

Не совсем. Здесь оно показывает только еще не выделенное пространство. Под что оно будет выделено - под btree или data - это уже не важно. Размеры файлов, каталогов показывает без учета сжатия родными утилитами, df показывает то же, что и в bcache fs usage, чего в BTRFS нет. Собственно, если там написано что свободно 210 гигабайт - то уж как минимум 209 гигабайт я туда запихаю... С btrfs это не гарантировано. В bcachefs в этом смысле алгоритмы намного продуманнее.
> Но некие аномалии все же вылезли.

Наверное, вы тыкали ZSTD. Там были грабли, при том вплоть до потери данных (повреждало файлы). Я почему-то посмотрев тесты и почитав ишью и багтрекеры решил, что lz4 спасёт отца русской демократии.

>2 типа - те кто еще не делает бэкапы и те кто уже делает.

На 4. Есть еще те, кто верифицирует бэкапы и те, кто тестирует восстановление из них (и я щас не про целостность архивов).

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

131. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 17:52 
>>большая часть тулсов/либ в вашей системе еще не знает этот тип ФС.
> Manjaro unstable? bcachefs-tools из aur? Сомневаюсь ).

Да я даже из git автыря их билданул. А coreutils'ам и системде вы уже объяснили что такую ФС завезли? И они отрелизились новыми версиями с явным саппортом типа ФС? Да даже кернелу надо явно тип ФС тыкать, если это рутфс, иначе - ну вот таки не могет он его зацепить.

>>не маунтится mount'ом без явного указания -t bcachefs, автодетект не срабатывает.
> Это правда. Но оно не маунтилось у меня при задании сего действа
> в fstab (начинал с одного диска).

Ну вот где-то автодетект еще не допилен. Однако я бутанул VM с таким рутфс, так что на рутфс он сам по себе - работает. А, если кто хотел прям оттуда читать кернел и проч - ну, бутлоадеры тоже пока еще врядли кто заапдейтил уметь читать bcachefs.

Для btrfs grub это умеет, и сие довольно круто: можно бутануть СНАПШОТ по сути голыми руками, отыграв назад аж одним бутлоадером из всех системных тулсов. Мне такой рекавери системы нравится, почти как VM :)

> Ну у меня оно поверх luks, так что, может, я с коммандлайном
> ядра обгадился. Возможно. Родное шифрование я там тыкать пока что не
> захотел, смигрирую потом когда-нибудь.

Ну вот это уже довольно продвинутое комбо, я не смотрел как оно такое будет.

> Можно на лету поменять, это резерв для GC. Может и убрали, но
> у меня создана ФС была, когда он еще был. Мне не мешает.

Просто я довольно плотно смотрел изменения в этой штуке, продвинутые файлухи - это мне интересно. А упрямый независимый кодер, гнувший свою линию почти 10 лет - по своему прикольно. Будущее должно принадлежать вот таким.

> Не совсем. Здесь оно показывает только еще не выделенное пространство. Под что
> оно будет выделено - под btree или data - это уже не важно.

Намекаю: например, GC - это фоновая активность, кроме случаев когда конкретно приперло так что иначе совсем никак. Он когда-то что-то выцепит, но в общем случае не прямо вотпрямща. И это вероятно примерно одинаково что у btrfs что у bcachefs. Соответственно в счетчик free допустим удаление чего-то может попасть не сразу - дергать GC на каждый пшик неоптимальная идея, это делают только если с свободным местом совсем душняк но это крайне субоптимальный режим.

> Размеры файлов, каталогов показывает без учета сжатия родными утилитами,
> df показывает то же, что и в bcache fs usage, чего в BTRFS нет.

И все же - есть некая "асинхронность" и "неизвестные факторы".

> Собственно, если там написано что свободно 210 гигабайт
> - то уж как минимум 209 гигабайт я туда запихаю...

Оптимизм это хорошо. Попробуйте создавать файлы 0 байтов. Миллионами. В какой-то момент у вас кончится место - при формальной аллокации 0 байтов :P. Сколько и чего вы там записали? :)

> С btrfs это не гарантировано. В bcachefs в этом смысле алгоритмы намного
> продуманнее.

Оно на самом деле никогда не гарантировано на 100%. А так bcache самый поздний из дизайнов - и потому учел грабли предшественников. Btrfs-ники впрочем свои грабли тоже учитывать умеют.

>> Но некие аномалии все же вылезли.
> Наверное, вы тыкали ZSTD. Там были грабли, при том вплоть до потери
> данных (повреждало файлы).

Портить не портились - но RAM на мелкой VM в какой-то момент выжрало весь. Btrfs этим не страдает, соответственно.

> Я почему-то посмотрев тесты и почитав ишью и
> багтрекеры решил, что lz4 спасёт отца русской демократии.

Вопрос в том не заменило ли это частый баг на редкий и более сложно провоцируемый...

> На 4. Есть еще те, кто верифицирует бэкапы и те, кто тестирует
> восстановление из них (и я щас не про целостность архивов).

Ну вот блин, оверинженерия. Уже из 2 типов 4 отрастили :)

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

173. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (34), 08-Янв-24, 18:46 
>А coreutils'ам и системде вы уже объяснили что такую ФС завезли?

Ну у меня не рутФС, но кент как-то разрабатывает и молчит, что там какие-то патчи этим утилитам нужны? Значитк ак минимум у него все работает. Так что тут не факт. В чем там дело на самом деле лично у меня не хватает понимания сказать.

>Для btrfs grub это умеет, и сие довольно круто

Это очень хорошая фича и прям в некоторых случаях даже маст хэв. Но имеем что имеем.

>Ну вот это уже довольно продвинутое комбо, я не смотрел как оно такое будет.

Не согласен. luks сам по себе предоставляет блочные девайсы, на которых и развернут bcachefs, для которого это просто диски. Но да, к проблемам с монтированием оно отношение иметь может ). Но для ФС это не комбо - она по сути работает как задумывалось.

>Намекаю: например, GC - это фоновая активность, кроме случаев когда конкретно приперло так что иначе совсем никак.

Объясняю: в btrfs бывали случаи, что она показывает, что свободного места еще дохуха, а запись на нее или любое действие (в т.ч. и ребаланс) - ENOSPC. В bcachefs это немного по другому реализовано: оно берет тупо пустые buckets и сообщает их объем. Т.е. оно может показать свободным меньше места, чем есть на самом деле (потому что GC еще не отработал), а вот показать свободное место, когда его нету - не может. Вообще. Никак.

>И все же - есть некая "асинхронность" и "неизвестные факторы".

Да, но реализовано иначе и часть проблем не присутствует.

>Оптимизм это хорошо. Попробуйте создавать файлы 0 байтов. Миллионами. В какой-то момент у вас кончится место - при формальной аллокации 0 байтов :P. Сколько и чего вы там записали? :)

  btree:                    8.86 GiB           21838      1.80 GiB
это у меня сейчас. При вашем подходе будет расти btree, а свободное место в ФС будет таять. Это как иноды в ext. Но да, формулировка моего оптимизма не корректна, учту ).

>Btrfs-ники впрочем свои грабли тоже учитывать умеют.

Все могут учитывать. Я не говорю что btrfs совсем уж кусок того самого. Он кое-в чем не плох.

>Портить не портились - но RAM на мелкой VM в какой-то момент выжрало весь. Btrfs этим не страдает, соответственно.

Ну да, у меня 32G RAM, а вы тестировали в "стесненной среде обитания". Боюсь, на голом железе такая проблема никогда не была бы найдена, только специальное тестирование в виртуалках такие баги позволяет отловить.

>Вопрос в том не заменило ли это частый баг на редкий и более сложно провоцируемый...

lz4 у него там очень давно был запилен и т.к. это дефолтный алгоритм - я думаю, это маловероятно. А вот zstd по настоящему нормально тестить стали только в майнлайне.

>Ну вот блин, оверинженерия. Уже из 2 типов 4 отрастили :)

Ну вот лично я ко всем категориям принадлежал. Сначала у меня небыло бэкапов. Потом оказалось, что они не распаковываются. В следующий раз распаковалось, но файлы оказались битые. Теперь проверяется не только консистентность, но и распаковка в виртуальную среду.

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

260. Скрыто модератором  +/–
Сообщение от Аноним (-), 09-Янв-24, 01:45 
Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 15:15 
Сетап - для хомяка ноутбучный SMR на терабайт, в качестве кэша - Kingston UV400 га 240 гигабайт. Сжатие - lz4 в бэкграунде. Ну т.е. ссд в качестве writeback кэша, во время ребаланса происходит сжатие данных и запись на бэкграунд HDD. Минусы - то, что тулзы местами недоделанные. Например, если смотреть rebalance status - то нихрена непонятно, сколько ему еще ребалансить. Нельзя вызвать ребаланс самому или изменить триггеры, вызывающие ребаланс. Это не мешает, но я хочу, например, делать ребаланс чаще. Так же, например, изменение таргета для метаданных не заставляет при очередном ребалансе метаданные переносить с носителя на выбранный полностью, приходится лапками мув данных запускать. Мелочи, в общем. RAID5/6 использовать не рекомендуется пока, насколько я понял, а так же _нельзя_ использовать erasure coding - ибо нестабильно. А вымораживает меня то, что оно не дает винту стопнуть шпиндель - раз в секунду что-то читается, или журналы сбрасываются. Я пока не понял, можно ли журнал убрать с HDD. Жить не мешает, но т.к. все нужные данные обычно в кэше (там обычный LRU) - мне хочется, чтобы хард стопался через минут так 5 неактивности, а вот хрен то там. Подозреваю, в следующих релизах поправят. Если погуглить - есть жалобы на nocow - мол, корраптит файлы - вот это жирный косяк, но вроде по последним коммитам что-то в этом направлении было сделано в rc7). Есть жалобы, что девайс не всегда получается вывести из массива, но тут я не тестил - и, в общем, понятно, что это будет исправляться - вроде как в linux-next там на эту тему тоже что-то заброшено. Есть косяк, что если смотреть rebalance_status из sysfs - оно IO считает в каких-то странных единицах, ошибка в выводе времени отображения ожидания ребаланса (200 секунд отображаются как 200 минут, а 3600 секунд - как 3600 часов) - но, я так понимаю, Кенту на это начхать пока что, да оно и не важно.

Пережило с десяток отключений питания, нормально работает в гибернации (я использую для хомяка, корень у меня на другом SSD). Восстановление после сбоя бывает длительным, но пока ничего не потерялось.

Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd висла, поэтому на корень я бы это тоже ставить не стал.

Почему оно лучше чем btrfs - так это я свободное место могу нормально видеть, там зарезервировано, кстати, в дефолте 8%. По сравнению с ZFS - мне не нужен дикий ARC, который к linux VFS сбоку. И ни одна из них не умеет кэшить на SSD - есть просто bcache, который создает грабли с саспендом и гибернацией, есть LVM-cache, который настроить не просто (там считать надо) и с которым можно огрести неиллюзорные грабли.

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

uncompressed:
        nr extents:             3684626
        size:                   507 GiB
compressed:
        nr extents:             3724187
        compressed size:        216 GiB
        uncompressed size:      448 GiB
incompressible:
        nr extents:             10889179
        size:                   622 GiB

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

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

75. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 15:26 
> Сижу на этом с 6.7-rc1 и впечатления пока что только положительные.
> Есть минусы, но по сравнению с btrfs и zfs они просто ничтожны.

Как говорится храбрым поем мы славу. А я пару багов вот собрал - так что на основных системах спасиб но что-то не хочется. Кой-что уже починено, но... сыровата она пока.

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

81. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 15:32 
Естесно, что сыровата. У меня юзкейс примерно такой же, какой был бы на bcache (не fs), поэтому я особо париться не стал. Снепшоты мне нахрен не нужны, сабвольюмы тоже, nocow я не использовал (вот тут повезло). У меня, если что, бэкап припасён и делается раз в час всего, что мне надо - как бы пересоздать раздел и вытащить все из бэкапа - дело 10 минут и я знаю, на что иду. Так что про храбрость тут эт ты зря. Я ее использую потому, что тесты показали, а практика подтвердила - что оно мне жизнь упростило и волосы стали мягкими и шелковистыми. В бизнесовый прод это тащить, естесно, рано.
Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 16:40 
> Естесно, что сыровата. У меня юзкейс примерно такой же, какой был бы
> на bcache (не fs), поэтому я особо париться не стал.

Ну вот если кто юзал bcache, bcachefs это логичная для их пожеланий штука. Ибо это оно - но таки с filesystem-aware дизайном, что выглядит намного более удачной идеей.

Моя проблема с этим всем? Судя по багам я не уверен насколько безопасно там гонять на продвинутых комбо. Там и в базовых есть приколы. Но не фатальные. И покамикадзить - можно, с пониманием что EXPERIMENTAL никого ни к чему не обязывал.

> и вытащить все из бэкапа - дело 10 минут и я
> знаю, на что иду. Так что про храбрость тут эт ты зря.

Тогда возможно у вас много времени или данные не сильно ценные. А бэкап раз в час это круто. А сколько бэкапов и за какое время вы храните? Это полные бэкапы? Или некие дифференциальные?

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

Было бы нехило указать в чем именно жизнь проще стала :). Но вообще - файлуха интересная, баги - чинят, и довольно бодро. А Кенту всяческие респекты за упорство. Таки - дожал.

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

116. "Релиз ядра Linux 6.7"  +2 +/–
Сообщение от Аноним (34), 08-Янв-24, 17:06 
>гонять на продвинутых комбо.

Кому-то это придется делать, так или иначе. Я уверен, что если всякие комбинации строить - оно отыквится очень быстро. И включение этого дела в майнлайн, я надеюсь, даст возможность желающим протестить и выкатить багрепорты. Главное, чтобы люди понимали, что это "для энтузиастов".

>Тогда возможно у вас много времени или данные не сильно ценные. А бэкап раз в час это круто. А сколько бэкапов и за какое время вы храните? Это полные бэкапы? Или некие дифференциальные?

В машину подрублена флэшка на 128 гиг, реально нужных данных - около 80 гигабайт (включая ~/.local, ~/.config и вот это всё. Музыка хранится на своем Nextcloud, Игрушки и скачанная сторрентов развлекуха и сериалы за важные данные не считаю.
Бэкап делается borgbackup (рекомендую граф. оболочку vorta). Оно же и верифицирует. Т.к. мои нужные данные менются не то, чтобы целиком и полностью (пет-проекты, рабочие проекты, документы). Все данные, естесно, дублируются в NextCloud, а репозитории хранятся не только на локальной машинке, но и на сервере. Длинный только первый бэкап, потом оно клонирует только изменения (по сути подерживает репозиторий). Это не инкрементальные бэкапы в чистом виде. Подобным механизмом обладает и Proxmox Backup Server. По факту данные каждый раз дедуплицируются, получается. Надо мало места.

Если случится звяздец - просто mkfs /home && mkdir /home/user && chown && chmod, а дальше пинаем боргбэкап из консольки и идем пить кофе. Т.к. флэшка USB3 и довольно быстрая на чтение - данные поднимутся минут за 10 и можно будет работать с абсолютно того же места, попутно перекачивая всякую развлекуху с торрентов. Потеряю максимум час работы, на практике меньше, буду расстроен, но ничего критичного. Проблема только в том, что надо иногда бэкапить саму флэшку на всякий случай и лапками контролировать состояние бэкапа иногда.

>Было бы нехило указать в чем именно жизнь проще стала

У меня у ноутбуке два SSD по 256 гиг и один HDD SMR на терабайт. На один SSD положил корень с ext4, из второго SSD и HDD собрал бутерброд с bcachefs... Жизнь стала проще в том, что всякие проектики, всё что мне нужно для работы находится в пределах одной ФС лежат теперь на SSD, профили браузеров, настройки часто используемого софта, диски виртуальных машин (и не полностью, а только используемыми частями) - все это в кэше хранится, а всякая хрень лежит на HDD, которую тыкаешь раз месяц. Да, кэш при обращении немножко подмывается, но SSD достаточно большой. Да и сжатие... При таком сетапе в ФС влезает примерно 1,1 терабайта, но хранится на ней сейчас уже терабайт и свободно при этом 200 гиг ещё. И всё в одной точке монтирования.

>файлуха интересная, баги - чинят, и довольно бодро.

если она сможет то, что заявлено со временем - она похоронит и btrfs и ZoL. Так что долгой жизни Кенту и жену не убивать. Да и пока что она обладает несколько более простым дизайном, насколько я понимаю, чем BTRFS и ZFS и если код не превратится в блоатварь - всё будет прекрасно (я надеюсь).

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

137. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 18:05 
>>гонять на продвинутых комбо.
> Кому-то это придется делать, так или иначе.

...
> Главное, чтобы люди понимали, что это "для энтузиастов".

Ну вот мне - любопытно как оно будет на некоторых из моих кейсов. И как оно VS btrfs. И проч.

> В машину подрублена флэшка на 128 гиг, реально нужных данных - около
> 80 гигабайт (включая ~/.local, ~/.config и вот это всё.

Такие флешки довольно сыкотные штуки. Я бэкапаюсь на (физически отключаемый после бэкапа) винч. Так даже пых питальника, крутой сбой или саботаж системы типа dd в блочный девайс и проч не страшен.

> на своем Nextcloud, Игрушки и скачанная сторрентов развлекуха и сериалы за
> важные данные не считаю.

Это можно и перекачать.

> и Proxmox Backup Server. По факту данные каждый раз дедуплицируются, получается.
> Надо мало места.

Дедупликация в бэкапах имеет свои траблы - при отклонении от идеала будет ой. Это же касается и длинных цепочек дифференциальных бэкапов.

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

Ну вот да. Доверия USB флешкам, скажем прямо, немного.

> только используемыми частями) - все это в кэше хранится, а всякая
> хрень лежит на HDD, которую тыкаешь раз месяц. Да, кэш при
> обращении немножко подмывается, но SSD достаточно большой. Да и сжатие... При
> таком сетапе в ФС влезает примерно 1,1 терабайта, но хранится на
> ней сейчас уже терабайт и свободно при этом 200 гиг ещё.
> И всё в одной точке монтирования.

По своему прикольно. Я пока в такие продвинутости не лазил, у меня btrfs с снапшотами на корне и там где вы будете пить кофе, я за минуту бутлоадером в старое состояние вернусь - и если это не разрушение блочного девайса, "как будто ничего не было".

Я так разок отыграл на 1 компе неудачный апгрейд дебиана. Не понравилось как работает - ну и вернул за пару минут прошлую версию системы "в виде как было", 1 в 1.

> если она сможет то, что заявлено со временем - она похоронит и btrfs и ZoL.

Не уверен насчет btrfs - местами он имхо получше продуман, да и у них свои тузы в рукаве есть. А ZoL туда и дорога, я о out of tree уродах скучать не буду. Однако возможность многодевайсовых иерархий - это клево.

> Так что долгой жизни Кенту и жену не убивать. Да и пока что она обладает несколько
> более простым дизайном, насколько я понимаю, чем BTRFS и ZFS и если код не
> превратится в блоатварь - всё будет прекрасно (я надеюсь).

Пока код конечно заметно компактнее, но там и ряда фич нет. А пока все прикрутят, заоптимизят, зафиксят, ... ну блин, у меня самого иногда мелкая прога порой становится довольно увесистой такой штукой, почти на отдельный проект. А тут ФС целая.

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

181. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 18:57 
> Ну вот мне - любопытно как оно будет на некоторых из моих кейсов. И как оно VS btrfs. И проч.

Смотря для чего. Сжатие - огонь, оно вроде даже лучше чем у бэтра. Есть кэширование - что явно лучше чем у бэтра. Лично у меня ведет себя прекрасно. Всё остальное - хуже, инфа сотка.

>Такие флешки довольно сыкотные штуки. Я бэкапаюсь на (физически отключаемый после бэкапа) винч.

Ну поэтому флэшку тоже приходится бэкапить. А винт я ронял со стола со всеми вытекающими. SSD технически - та же флэшка. Так что так вот и живем.

>Дедупликация в бэкапах имеет свои траблы - при отклонении от идеала будет ой. Это же касается и длинных цепочек дифференциальных бэкапов.

Поэтому верификация и делается. Это фактически возможность распаковки проверяется. У меня - раз в неделю.

>, у меня btrfs с снапшотами на корне и там где вы будете пить кофе, я за минуту бутлоадером в старое состояние вернусь

А если "ФС быканет"? Не вернетесь. Снепшот -не бэкап, bcachefs тоже снепшоты умеет. Но, я боюсь, например, при порче суперблоков - снепшоты не жильцы.

> местами он имхо получше продуман, да и у них свои тузы в рукаве есть.

Одного поля ягоды. Просто bcachefs сможет очень таки не хило использоваться в файлопомойках, NAS, да и просто на десктопах, где 20 Тб SMR винт и приправлен терабайтным SSD. Это просто удобно и простой способ поднять отзывчивость хранилищ. Остальные фичи - такие же как и btrfs/zfs. Ну будет btrfs развиваться параллельно, никто его не выкинет просто так, а надобность в ZFS она отпадёт. BTRFS просто менее надежен By Design чем тот же ZFS. Если Bcachefs получит возможности btrfs и надежность zfs - он сожрет их обе когда-нибудь, вместе с ext4, lvm, luks, mdadm. Но вряд ли это случится в ближайшие 20 лет.

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

264. Скрыто модератором  +/–
Сообщение от Аноним (-), 09-Янв-24, 02:14 
Ответить | Правка | Наверх | Cообщить модератору

294. "Релиз ядра Linux 6.7"  +/–
Сообщение от Shevchuk (ok), 09-Янв-24, 07:14 
> Всё остальное - хуже, инфа сотка.

Разверните плз — интересно.
Я конечно скоро и сам погоняю тесты, но чужой опыт тоже полезен.

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

483. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (483), 22-Янв-24, 07:07 
Да нечего разворачивать. По скорости и удобству - проигрывает, половина из заявленного не реализована, еще половина из реализованного - experimental. Так что аккуратно тут... Ну и в экзотических случаях не протестировано.
Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 08-Янв-24, 14:39 
А причинами поинтересоваться?
Btrfs поддерживает несколько режимов хранения в пределах одного волюма, т.е часть файлов может лежать в raid0, а часть в raid1
Сколько места осталось зависит от того, как ты файлы будешь записывать
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

68. "Релиз ядра Linux 6.7"  +/–
Сообщение от t (??), 08-Янв-24, 15:16 
а как такое реализовать? это вот то что мне надо, но как сделать такое физически я не нашел.
Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 15:28 
Никак. Потому, что RAID в бэтре - это почти фикция.
Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 16:41 
> Никак. Потому, что RAID в бэтре - это почти фикция.

Вот неправда ваша - RAID1 и DUP в btrfs совершенно точно работает. Вполне нормально. И весьма недурно парирует отклонения от идеала, даже довольно дурацкие, типа накопителя выдающего левак или бэдсектор.

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

121. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 17:16 
Я не говорил, что он не работает. Я говорил, что он не спасет от проблем ФС, а проблемы у этой ФС при сетапе RAID0/RAID1 на одной файловой системе будут.
Ответить | Правка | Наверх | Cообщить модератору

138. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 18:07 
> Я не говорил, что он не работает. Я говорил, что он не
> спасет от проблем ФС, а проблемы у этой ФС при сетапе
> RAID0/RAID1 на одной файловой системе будут.

Странно - как же я тогда RAID1 пользуюсь? Нельзя ли поподробнее о том какие именно у меня должны быть проблемы с RAID1?

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

182. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 18:58 
>> Я не говорил, что он не работает. Я говорил, что он не
>> спасет от проблем ФС, а проблемы у этой ФС при сетапе
>> RAID0/RAID1 на одной файловой системе будут.
> Странно - как же я тогда RAID1 пользуюсь? Нельзя ли поподробнее о
> том какие именно у меня должны быть проблемы с RAID1?

Чукча не читатель? Часть ФС в RAID1, часть в RAID0. ВОт про это разговор.

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

333. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 09-Янв-24, 18:14 
>> Странно - как же я тогда RAID1 пользуюсь? Нельзя ли поподробнее о
>> том какие именно у меня должны быть проблемы с RAID1?
> Чукча не читатель? Часть ФС в RAID1, часть в RAID0. ВОт про это разговор.

Это несколько отличается от "RAID в бэтре - это почти фикция" я б сказал. RAID1 в нем совершенно точно работает и никаких особых косяков с этим нет. Прекрасно достает копию взамен профакапленой и чинит в фоне например.

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

97. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 08-Янв-24, 16:11 
А вот с этим есть ньюанс, пока это не настраивается)
Можно получить смешанную фс если начать ребаланс с -dconvert, и не закончить его. Старые файлы останутся со старым raid, новые будут с новым.
В будущем когда-то профиль будет настраиваем per-file/per-subvelume. Однако корень этого функционала уже реализован, и в mixed режиме ФС работает, ну и соответственно реализации df это мешает
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

110. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 16:44 
> Можно получить смешанную фс если начать ребаланс с -dconvert, и не закончить
> его. Старые файлы останутся со старым raid, новые будут с новым.

Можно также просто выставить новые дефолты - и вообще ничего не конвертить. Новые записи будут в новом формате, старые - в прошлом. Самому по себе дизайну этой штуки - оно нормуль. Он для порядка скажет в dmesg что видит такое, но ни к каким проблемам это не ведет.

> соответственно реализации df это мешает

Если кто не в курсе, Кент уже и 8% расхотел резервить, и ENOSPC vs GC познал, и некие фиксы отображения свободного места - таки ну вот concern в продвинутом дизайне, у которого возможно не тупое как дрова поведение а некая палитра действий.

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

117. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 17:10 
> Если кто не в курсе

И баги эти уже исправил.

>некие фиксы отображения свободного места

Собственно, это фиксы не того случая, когда свободного места нет, а оно показывается. В bcachefs это by design не может быть.

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

140. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Янв-24, 18:11 
>> Если кто не в курсе
> И баги эти уже исправил.

Да он там хорошо разогнался, раза три фиксил. Попользовавшись -rc по полной.

>>некие фиксы отображения свободного места
> Собственно, это фиксы не того случая, когда свободного места нет, а оно
> показывается. В bcachefs это by design не может быть.

Мне кажется что вы несколько идеализируете design и что в таких штуках (не)может быть. Даже для классики можно - вот - аллицировать хоть все место под метаданные, не записав в регион данных ни байта. При этом формально мы ни 1 байта на полезное содержимое не тратили - а места нет. На этом эффекте какой-то юморист даже архивер писал, он все данные распихивал в ИМЕНА файлов, это была попытка выиграть контест сжатия. Он спросил можно ли несколько файлов. Можно! Ну он и! Формально суммарный вес данных файлов - ноль :). А то что все ушло в метаданные... не, приз ему вроде таки не дали - это читерство. Де факто вся просто аллокация ушла в метаданные. И вот это есть даже в совсем классических ФС.

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

185. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 19:03 
>ллицировать хоть все место под метаданные, не записав в регион данных ни байта.

Проблема в том, что в bcachefs место, аллоцированное под метаданные считается занятым. Т.е. аллокация этого пространства -> 0 свободного места в df. В btrfs (устал уже повторяться) - свободно 50 гигабайт, а записать в нее ничего не можем. Ребаланснуть не можем, удалить ничего не можем, потому что места мало.

В btrfs все пространство поделено на так называемые buckets.И если все buckets аллоцированы - оно не покажет свободного места.

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

266. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 09-Янв-24, 02:23 
> Проблема в том, что в bcachefs место, аллоцированное под метаданные считается занятым.

Оно у всех будет откусывать от свободного места. Просто потому что описание создаваемых файлов надо где-то хранить. Так что то что df кажет и то что будет на самом деле - совпадать не обязано. А файлы 0 размера - это дурной утрированый пример, когда ФС целиком из метаданных состоит. Данных и нет. И вот все место спущено - при том что суммарный вес файлов 0 байтов.

В менее дурных случаях - data to metadata ratio не есть мировая константа и варьируется в зависимости от того что записываем.

> нее ничего не можем. Ребаланснуть не можем, удалить ничего не можем,
> потому что места мало.

На данный момент такое поведение не является типичным.

> В btrfs все пространство поделено на так называемые buckets.И если все buckets
> аллоцированы - оно не покажет свободного места.

Не, не так. В btrfs оно аллоцируется в chunks. И если все аллоцировано, есть некоторые проблемы с data to metadata ratio если вдруг оно круто изменится. Но вообще с неких пор оно умеет подгребать малоиспользуемые chunks и как я уже сказал - по общей идее действа оба дизайна как бы конвергируют к чему-то похожему, с разных сторон (у bcachefs аллокация buckets, по иным правилам, и они довольно мелкие, а chunk btrfs - типично гиг, но можно и изменить вроде, одно время по 5 делали по дефолту но это оказалось плохой идеей и вернули как было).

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

239. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (239), 08-Янв-24, 23:42 
Там ещё нюанс, само упоминание будущих планов по реализации такого замечательного режима хранения данных найти можно только в кеше гугла со старого их сайта. А если не копаться в старых, сто лет назад удаленных, планах то окажется, что нет и никогда не будет никаких per-file и per-sub. Было бы хорошо, но нет.
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

263. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 09-Янв-24, 02:12 
> окажется, что нет и никогда не будет никаких per-file
> и per-sub. Было бы хорошо, но нет.

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

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

74. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 15:24 
И на кой это ей, если она сама рассыплется так, что костей не соберешь при исправных накопителях? Имею опыт рассыпания этой ФС без всяких рейдов, данные спасти не удалось от слова совсем, потому что похерилось b-дерево полностью каким-то образом. Собсна, все эти рейды в btrfs, насколько я понимаю - та еще лотерея, т.к. метаданные если криво запишет - они не спасут. А у бэтра это самая частая проблема, если железки будут консьюмерские и не особо дорогие. Так как другие ФС так не дохнут - то, собсна, ой. А ещё этот бэтр при scrub у меня находил коррапченные файлы...

Переусложненная и с хреновым дизайном она.

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

79. "Релиз ядра Linux 6.7"  +2 +/–
Сообщение от Аноним (-), 08-Янв-24, 15:30 
> И на кой это ей, если она сама рассыплется так, что костей не соберешь
> при исправных накопителях? Имею опыт рассыпания этой ФС без всяких рейдов,
> данные спасти не удалось от слова совсем,
> потому что похерилось b-дерево полностью каким-то образом.

Вообще-то на нормальных накопителях и исправном железе b-деревья не улетают вникуда. У вас никаких чудес типа дров от нвидии не было случайно? Они не так давно чудно выносили ядерную память через DMA и по этой линии я видел трупы как минимум XFS, EXT4 и btrfs.

> Переусложненная и с хреновым дизайном она.

Обычно вон то случается у владельцев глюкавого хардвара где ext4 как-то коптил но работал, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы. Или у счастливых обладателей глючных конфиг рушаших память так или иначе.

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

88. "Релиз ядра Linux 6.7"  –1 +/–
Сообщение от Аноним (34), 08-Янв-24, 15:46 
>Вообще-то на нормальных накопителях и исправном железе b-деревья не улетают вникуда.

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

Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС. Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на другой системе), но перезагрузка штатная и fsck решала. Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если бы это был btrfs - с данными я бы попрощался.

>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы.

Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем на том же сетапе. Вот в чем бяда. И если ext4/xfs в общем-то попроще значительно, то ZFS - мультикомбайн шиздец какой и тоже переусложнён на мой взгляд местами (имею опыт восстановления с него данных - разобраться во всех его кишках было очень проблематично).

Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так - то RAID становится бесполезен. И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу? В случае с RAID0 они размазываются на два диска как RAID0? =).

Да и с raid1 замена диска - печаль:
Device removal must satisfy the profile constraints, otherwise the command fails.
Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате в тот же RAID0 можно здорово обгадиться при конверте в RAID10. Собсна, потому и говорю, что переусложнена - действия, которые должны быть простыми для пользователя, зачастую, оказываются весьма не тривиальными.

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

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

Вообще-то при этом буфера сбрасываются и проч. Возможно в этот момент пошло что-то очень сильно не так - и память вынесло настолько что аж "ноутбук не проснулся".

В нормальном железе с безглючным low level софтом - вон того не бывает.

> Скорее всего, оно по какой-то причине его полностью решило пересобрать или
> не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает.

Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился, и что там в ФС записалось, возможно при сбросе буферов - ктулху б его знает.

> Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС.

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

> Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на
> другой системе), но перезагрузка штатная и fsck решала.

Это видите ли когда как. Везение имеет свойство заканчиваться.

> Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если
> бы это был btrfs - с данными я бы попрощался.

На btrfs в случае чего как-то больше опций потрепыхаться - запись изначально недеструктивная, это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. А в EXT4 если что-то не то запислось - упс, никаких старых версий и альтернатив, картина репина приплыли. И если fsck не выдюжил или полегло много...

>>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы.
> Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем

Если хардавар не выходит из хибернации - он не в порядке. Если рушится EXT4 - тоже что-то идет не так.

> - разобраться во всех его кишках было очень проблематично).

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

С другой стороны дизайн btrfs я более-менее раскурил. Bcachefs субъективно более хаотичный и там меньше архитектуры. Но общие core идей слизаны с btrfs.

Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... реалии, конечно, оказались чуть прозаичнее. Перфоманс у bcachefs пока не чемпионский, фороникс даже уже померял чутка. А без backrefs операции связанные с троганием данных из логического смещения (ремув девайса, ряд сервисных операций и проч) - таки тупят и вон там Кент уже задумался что какой-то индекс нехило бы. Если его в рантайм строить это ессно просадит перфоманс. А если "когда потребовался" - это роняет перфоманс операций менеджмента. Такой вот tradeoff.

> Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так
> - то RAID становится бесполезен.

На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. Если конечно данные факапнулись в памяти еще до того как в RAID отреплицировано - против такого лома приема конечно нет. Но с "ram corruption" что угодно дохнет, и я не только видел прецеденты но и данные с такого рекаверил, довольно неудобно ибо там обычно живого места нет.

> И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу?

По какому настроите! Хоть RAID1C4 (4 копии) - если девайсов на это есть и увеличение вчетверо не парит. Но такой хардкор имеет смысл имхо на конфиге с ECC, и заведомо стабильной системе.

У btrfs могут быть разная схемы для данных и метаданных, более того - можно на ходу рестрайпнуть, это даже относительно безопасно благодаря логике CoW (у меня как-то powerloss был на компе где я конвертил схему).

У bcachefs примерно та же идея. Кент передрал эту клевую идею. Воон там выбирается число копий и данных, и метаданных. В mkfs - точно. В рантайм, как в btrfs, переигровку реплик - пока не пробовал с ним, но вроде тоже можно.

> Да и с raid1 замена диска - печаль:
> Device removal must satisfy the profile constraints, otherwise the command fails.

Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, если девайс живой, но его хочется вынуть, лучше btrfs device add нового, и потом remove старого. С него будут удвинуты данные - в том числе и на новый.

Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой. Тоже обыгрывается как add нового -> remove старого, и там подшаманить профайл метаданных как раз придется - оно заметив второй диск радостно RAID1 для метаданных начинает юзать. Это немного клещится с планом вон тот девайс отобрать. Но решаемо конверсией профайла метаданных. Если кто захочет это повторить - не забудьте бутлоадер и загрузочные флаги на новом накопителе, иначе можно будет немного обломаться.

FS UUID при этом фокусе не меняется, так что менять монтирование рутфс и проч не надо.

> Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате
> в тот же RAID0 можно здорово обгадиться при конверте в RAID10.

В btrfs мало чего прибито на гвозди. Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу. И это безопаснее чем в других штуках. Оно аллоцирует данные в чанках, у чанка есть "схема хранения".

И конверсия профайла это так: берется файл и его данные, из чанков старого типа. Пишется в новые, с новой схемой. Если прокатило - "указатели" в метаданных начинают показывать на новый вариант, и процесс продолжается. А при крахе - старое состояние никуда не делалось, новая недописаная версия - игнорится, ее еще не успели пометить как аллокацию.

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

Звездо> На нормальных ФС они вникуда не улетают. После гибернации ноутбук не проснулся.
Вообще-то при этом буфера сбрасываются и проч. Возможно в этот момент пошло что-то очень сильно не так - и память вынесло настолько что аж "ноутбук не проснулся".

В нормальном железе с безглючным low level софтом - вон того не бывает.

> Скорее всего, оно по какой-то причине его полностью решило пересобрать или
> не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает.

Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился, и что там в ФС записалось, возможно при сбросе буферов - ктулху б его знает.

> Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС.

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

> Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на
> другой системе), но перезагрузка штатная и fsck решала.

Это видите ли когда как. Везение имеет свойство заканчиваться.

> Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если
> бы это был btrfs - с данными я бы попрощался.

На btrfs в случае чего как-то больше опций потрепыхаться - запись изначально недеструктивная, это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. А в EXT4 если что-то не то запислось - упс, никаких старых версий и альтернатив, картина репина приплыли. И если fsck не выдюжил или полегло много...

>>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы.
> Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем

Если хардавар не выходит из хибернации - он не в порядке. Если рушится EXT4 - тоже что-то идет не так.

> - разобраться во всех его кишках было очень проблематично).

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

С другой стороны дизайн btrfs я более-менее раскурил. Bcachefs субъективно более хаотичный и там меньше архитектуры. Но общие core идей слизаны с btrfs.

Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... реалии, конечно, оказались чуть прозаичнее. Перфоманс у bcachefs пока не чемпионский, фороникс даже уже померял чутка. А без backrefs операции связанные с троганием данных из логического смещения (ремув девайса, ряд сервисных операций и проч) - таки тупят и вон там Кент уже задумался что какой-то индекс нехило бы. Если его в рантайм строить это ессно просадит перфоманс. А если "когда потребовался" - это роняет перфоманс операций менеджмента. Такой вот tradeoff.

> Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так
> - то RAID становится бесполезен.

На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. Если конечно данные факапнулись в памяти еще до того как в RAID отреплицировано - против такого лома приема конечно нет. Но с "ram corruption" что угодно дохнет, и я не только видел прецеденты но и данные с такого рекаверил, довольно неудобно ибо там обычно живого места нет.

> И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу?

По какому настроите! Хоть RAID1C4 (4 копии) - если девайсов на это есть и увеличение вчетверо не парит. Но такой хардкор имеет смысл имхо на конфиге с ECC, и заведомо стабильной системе.

У btrfs могут быть разная схемы для данных и метаданных, более того - можно на ходу рестрайпнуть, это даже относительно безопасно благодаря логике CoW (у меня как-то powerloss был на компе где я конвертил схему).

У bcachefs примерно та же идея. Кент передрал эту клевую идею. Воон там выбирается число копий и данных, и метаданных. В mkfs - точно. В рантайм, как в btrfs, переигровку реплик - пока не пробовал с ним, но вроде тоже можно.

> Да и с raid1 замена диска - печаль:
> Device removal must satisfy the profile constraints, otherwise the command fails.

Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, если девайс живой, но его хочется вынуть, лучше btrfs device add нового, и потом remove старого. С него будут удвинуты данные - в том числе и на новый.

Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой. Тоже обыгрывается как add нового -> remove старого, и там подшаманить профайл метаданных как раз придется - оно заметив второй диск радостно RAID1 для метаданных начинает юзать. Это немного клещится с планом вон тот девайс отобрать. Но решаемо конверсией профайла метаданных. Если кто захочет это повторить - не забудьте бутлоадер и загрузочные флаги на новом накопителе, иначе можно будет немного обломаться.

FS UUID при этом фокусе не меняется, так что менять монтирование рутфс и проч не надо.

> Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате
> в тот же RAID0 можно здорово обгадиться при конверте в RAID10.

В btrfs мало чего прибито на гвозди. Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу. И это безопаснее чем в других штуках. Оно аллоцирует данные в чанках, у чанка есть "схема хранения".

И конверсия профайла это так: берется файл и его данные, из чанков старого типа. Пишется в новые, с новой схемой. Если прокатило - "указатели" в метаданных начинают показывать на новый вариант, и процесс продолжается. А при крахе - старое состояние никуда не делалось, новая недописаная версия - игнорится, ее еще не успели пометить как аллокацию.

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

На самом деле эти звездолеты с машиной времени довольно просты в пилотировании - после того как основные принципы поймешь. Да, это отличается от классики. И только. У Кента на мой вкус управление пока немного хаотичнее но в целом по образу и подобию, ибо общие идеи такие же. С прикручиванием к bcachefs-like идее, что так то добавляет аспектов в управлении.

У кента можно нарулить иерархическую хранилку - с записью на быстрый буфер и медленным реплицированием с него вооон туда, и кешированием "горячего" на быстрый носитель. Но при этом в отличие от bcachefs оно явно в курсе реплик и их состояния. Так что вероятно будет несколько лучше bcache - который легко убивает файлухи наповал как только быстрый накопитель затерся.

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

45. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (45), 08-Янв-24, 13:51 
>ZFS. Продавшиеся же давно
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

134. "Релиз ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (34), 08-Янв-24, 18:01 
>В нормальном железе с безглючным low level софтом - вон того не бывает.

Бывает всякое. Да, накрути ECC-память, диски с суперконденсаторами, да строго соответствующие спецификации и т.п. А надо, чтобы работало на обычном консьюмерском железе, которое исправное, но вот может не успеть, например, сбросить кэш при выключении при некотрых специфических условиях. И то, что ФС потеряла b-дерево и не смогла обратитсья к предыдущей его копии - это, таки, настораживает, бо в суперблоке должна быть ссылка и на старые и на новые данные.

>Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился

"не проснулся" в данном случае означает, что он тупо завис после выхода из гибернации на картинке логина. И это не говорит о том, что RAM порушилась, т.к. после реинсталла ОС и на другой ФС этот же ноут отработал ещё 5 лет без единого сбоя, пока я его кофе не напоил. Были какие-то специфичные условия, которых btrfs не пережила. Я же не зря выше оговорился, что проблемы у нее будут на "не дорогом консьюмерском" оборудовании.

>Это очень храброе утверждение

Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных, записанную ранее и не может отреплеить журнал. Т.е. у нас фактически запись не прошла и мы не можем смонтироваться - так надо реплеить журнал, которого не оказалось, вместе с b-деревом. Точнее, оно там было и я уверен, что восстанови я структуру вручную или обратись к тем, кто понимает структуру этой ФС на уровне разработчиков - все бы оттуда вытащилось. Оборудование, кстати, больше не сбоило.

>Это видите ли когда как. Везение имеет свойство заканчиваться.

Это разница в подходе. Когда ext4 обнаруживает, что crc в метаданных не совпадает - оно начинает ругаться и прекращает всческую запись, уходя в RO. BTRFS в аналогичной ситуации проблем не заметит, т.к. она их замечает только при очередном scrub.

>больше опций потрепыхаться

Больше секса без видимого результата. Могу и по пунктам, но ext4 _значительно_ проще в силу того, что btrfs всё же CoW. И сырые данные с BTRFS восстановить почти не возможно, если будет утеряна структура ФС в силу CoW (упс).

>это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч.

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

>Если хардавар не выходит из хибернации - он не в порядке

Софт безгрешен?

>Если рушится EXT4 - тоже что-то идет не так.

Да. В ядре 6.7 менялись некоторые механизмы, ога. Отсюда и проблема была, хи хи. И хардварь конкретно в данном баге ну вот вообще не при делах. При том, что из гибернации выходит и работает и даже может _штатно_ перезагрузиться.

>но и - это еще и бессмысленно. Я не понимаю почему это недоразумение - замечательно.

В сравнении с btrfs у него хотя бы аналог RAID5 работает и необходимости ребаланс (resilver) на каждый чих делать нет. А еще оно умеет в slog и L2ARC, оно ЗНАЧИТЕЛЬНО надежнее btrfs by design. Но формат там весьма сложен, да.

>Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит...

Не думаю, что он вот именно так рассуждал, но в отличие от btrfs он тянет лямку в одно хлебало. Тесты похороникса вообще с реальностью ничего общего зачастую не имеют.

>На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях.
>Но с "ram corruption" что угодно дохнет,

Записываю: btrfs безгрешен и ошибок в алгоритмах иметь не может. Ещё раз: даже если это был @ram corruption@ - данные должны быть восстановимы. Всё.

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

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

>По какому настроите!

Ага. Т.е. если изначально это был RAID0, то при превращении в RAID10 метаданные останутся в RAID0, ибо в документации это написано, но недостаточно очевидно. Хе-хе.

>Кент передрал эту клевую идею.

Тваю за ногу... bcachefs родилась из bcache, а не btrfs. И да, число копий метаданных настраивается, но не так, как в btrfs. И число данных тоже. Там каждый девайс имеет параметр durability. Т.е. при создании ФС указываешь число реплик для данных и метаданных и дальше при добавлении девайсов просто указываешь ему durability. Ты даже можешь raid аппаратный подсунуть и указать durability ему выше единицы, тогда данные, записанные на такой девайс могут и не реплицироваться, например. И т.д. и т.п. У btrfs же какаой-то секс с профилями и прочим При том - не всегда очевидный. Не надо говорить, что кто-то у кого-то передрал. Смиритесь, что некоторые вещи где-то могут быть реализованы лучше, а где-то хуже.

>Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше,

Бла-бла-бла. Посыл был не об этом. Если я хочу вынуть девайс из рейда - должно быть максимум две команды (отправить его в статус fail, а после вынуть). Но там предлагается несколько больше...

>Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой

Охренеть странные вещи. Любой raid-контроллер, mdadm, LVM, ZFS это позволяют. И даже bcachefs.
Дальше все что описано - ну ... Дичь же. Не надо ничего нигде шаманить - помечаем устройство сбойным и ынимаем, либо сразу вынимаем... Без шаманств с профайлами метаданных. Почему в btrfs это сложнее?

>Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу

Вообще-то я про неочевидность говорю. То, что это можно - это несомненный плюс.

>На самом деле эти звездолеты с машиной времени довольно просты в пилотировании - после того как основные принципы поймешь.

Да да да. Всё просто, когда знаешь. Мне вот ZFS сейчас проще кажется ;).

>ибо общие идеи такие же

Общие идеи - они впринципе проистекают как раз от ZFS, если уж так судить, да и до нее промелькивали. А про хаотичность... Ну не знаю, не знаю. Будем посмотреть, btrfs все же корпорации делать пытались, а не какой-то перец в одно хлебало.

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

Эээ... Оно их убьет наповал, если там writeback. В остальном - ничего он не сломает. А у случае с writeback - ну... таки здесь как раз тот случай, когда сам по себе тип кэша именно смерть ФС при повреждении и подразумевает.

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

143. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 08-Янв-24, 18:16 
> Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных, записанную ранее и не может отреплеить журнал. Т.е. у нас фактически запись не прошла и мы не можем смонтироваться - так надо реплеить журнал, которого не оказалось, вместе с b-деревом.

О каком журнале вообще речь? В btrfs CoW, не журналирование

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

149. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 18:20 
CoW и журналирование это вообще разные вещи. Вон в bcachefs есть и журналирование и CoW. А в BTRFS накосячили By Design. Поэтому она такая ненадежная, ну. Нормальная ФС _знает_, что запись не прошла после резкого отключения питания. А BTRFS - _не знает_.
Ответить | Правка | Наверх | Cообщить модератору

350. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (151), 09-Янв-24, 23:03 
> CoW и журналирование это вообще разные вещи. Вон в bcachefs есть и
> журналирование и CoW. А в BTRFS накосячили By Design. Поэтому она
> такая ненадежная, ну.

Поразвелось экспертов млин. Там ващет есть некий минимальный журнал под внутренние нужды, просто он далеко не главный элемент пейзажа в случае CoW, которые эквивалент полного журналирования достигают несколько иначе - сделав "журналом" всю площадь ФС. Откуда и нужда в GC, дабы неактуальное подчищать. Иначе из-за недеструктивной записи в сторону место постепенно кончится. Сложный GC и отложенная по времени деаллокация - это обратная сторона таких паттернов дизайна. В большинстве случаев это не проблема, но на интенсивно нагруженной ФС, забитой под завязку это следует учитывать по линии рисков ENOSPC (если забыть про фрагментацию и проч).

> Нормальная ФС _знает_, что запись не прошла после
> резкого отключения питания. А BTRFS - _не знает_.

А ему оно на самом деле и не надо. В CoW запись недеструктивная. И это как-то так: пишется новое, если прокатило - на это перевешивается "указатель" (апдейтятся метаданные). Если не прокатило (крах), то что получается - аналог 100% rollback зафейленых потуг. Ибо той записи никогда не существовало, это неаллоцированое место а вид ФС "немного более старый". А старое состояние никто и не уничтожал. Когда-то потом, если вон там все прокатило, за ним может и пришел бы GC, если больше никому эти блоки не нужны были.

Btrfs забавен тем что делает "рекурсивный" вариант трюка - к метаданным это все тоже применяется, по своему красивый фокус, изначально разработка кого-то из IBM чтоли.

Технически это эквивалент полного журналирования. Только без тормозов от двукратной записи. И таки слеты питания оно вполне себе переживает в общем случае. В частных - выключение SSD, и вообще флешатины, без команды шатдауна ДО снятия питания является технически-некорректным деянием (FYI - логится в смарте) и там уже никто ничего не гарантирует, начиная с производителя накопителя. Так что если что - а вот там в смарте все ходы записаны!

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

148. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 08-Янв-24, 18:19 
И вообще судя по другим веткам... Ты случаем не использовал writeback кеш с btrfs?
Потому что он с btrfs не работает, writeback кеш ломает CoW by-design
Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

152. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 18:23 
writeback кэш ничего не ломает. Writeback ломает только в том случае, если его что-то скорраптит. Но в случае с btrfs кэширование было writethrough, потому что я боялся, что SSD сдохнет из-за износа в силу непонимания реального ресурса NAND.
Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 08-Янв-24, 18:27 
> writeback кэш ничего не ломает.

Btrfs написан так, что ожидает что записи на диск пройдут в определённом порядке
Сначала дерево обновили, затем записали указатель

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

Существует не так много способов получить catastrophic failure на btrfs, и это один из них.

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

189. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (34), 08-Янв-24, 19:08 

>Btrfs написан так, что ожидает что записи на диск пройдут в определённом порядке

Ну. А если у диска отработал NCQ и пропало питание (часть данных не записалась) - то данные запишутся уже не в том порядке. Поэтому btrfs может сдохнуть просто на носителе с большим буфером, который не успеет сбросить все на блины, и на твердотельнике с большим DRAM при активной записи и удраконенном флэше без всяких кэшей.

>В случае с writeback, реальные записи на диск могут пройти в произвольном порядке, и вот тогда уже всё может сломаться, поскольку может возникнуть например ситуация что был записан указатель на ещё не существующую ветвь дерева.

Как это повлияет на ФС, если не записанные данные читаются из кэша, а не с бэкграунда? Никак. А вот если часть кэша пропадет внезапно - хана файлухе.

До меня дошло. Ты, наверное, про writeback в RAM? Неа. Writeback на SSD я счас использую. Т.е. SSD у меня Writeback-кэш, а не оперативка, которая будет потеряна при сбое питания. Тогда это был bcache с writethrough.

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

267. "Релиз ядра Linux 6.7"  +/–
Сообщение от morphe (?), 09-Янв-24, 02:24 
> А если у диска отработал NCQ

Btrfs следит за тем в каком порядке данные доходят до диска, однако в случае с bcache "диск" ответит об успешности записи моментально, и btrfs будет считать что запись действительно прошла. И до реального диска они дойдут в произвольном порядке уже, т.к тут btrfs уже не знает что происходит.

> Ты, наверное, про writeback в RAM?

Нет, про любое writeback кеширование в bcache для btrfs. Это где-то в lkml обсуждалось, но лень искать, а в arch wiki есть такой вот блок текста

Bcache write caching can cause a catastrophic failure of a btrfs filesystem.
Btrfs assumes the underlying device executes writes in order, but bcache writeback may violate that assumption, causing the btrfs filesystem using it to collapse.
Use bcache in writeback mode with btrfs at your own risk.

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

359. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 10-Янв-24, 01:30 
> Ну. А если у диска отработал NCQ и пропало питание (часть данных
> не записалась) - то данные запишутся уже не в том порядке.

Для начала - вы ОБЯЗАНЫ подавать команду шатдауна до снятия питания с SSD, если кто вдруг не в курсе. По спекам. Нарушение этого условия зачастую логгится и накручивает соотв счетчик, так что если что, гарантия там и проч, вам видимо этот счетчик и предъявят. "Нарушение условий эксплуатации".

При снятии питания без предупреждения с флешовыми девайсами может быть что угодно, в зависимости от дури фирмвари, интенсивности записи и вашего (не)везения. Вплоть до слета трансляции или продолба здоровенных ERASE BLOCK'ов которые оно там в фоне ворочало во имя GC на уровне своего FTL и проч. И нет, никакая фс не готова к тому что кус на ...цать мегов просто возьмет и продолбается. Ну, btrfs с избыточностью -  починит, конечно и это тоже, если было откуда. Собссно scrub имеет смысл пинать для обнаружения таких подарков. Потому что обнаружить что копия данных битая в момент когда она понадобилась - довольно хреново.

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

484. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (483), 22-Янв-24, 07:18 
Т.е. я при перезагрузке сервера по питанию должен как-то при его зависоне подать команду отключения во флэш? Вот насмешили. И продолб 20 метров - вот ваще не проблема для нормальной ФС. Ну, а на счет флэша с дерьмовымми прошивками... НУ да, могут сдохнуть. Но тут даже HDD могут сдохнуть во время внезапного пропадания питания (запил поверхности, отвал головок от удара об рампу, вынос медиакэша к чертям - так вообще продолб минимум 50G минфы (если очень повезет, а обычно - слет транслятора). Чего уж тут. Речь идет о том, что нормальная ФС маленько по иному барьеры расставляет и данные на диск раскладывает (если они важны) в несколько копий. А не так, что бэкап суперблока один на устройство.
Ответить | Правка | Наверх | Cообщить модератору

487. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 23-Янв-24, 07:24 
> Т.е. я при перезагрузке сервера по питанию должен как-то при его зависоне
> подать команду отключения во флэш? Вот насмешили. И продолб 20 метров
> - вот ваще не проблема для нормальной ФС.

Учитывая что это RMW + GC, там в принципе бывает что угодно, смотря насколько дурная фирмварь и ее логика и что там случилось. Это - unspecified!

Может слететь партишн. Особенно если вы не в курсе концепции Erase Block/Erase Group и не сделали выравнивание и "guard area".

Может слететь суперблок. Или дохрена метаданных. Btrfs с его DUP и несколькими суперами даже сможет потрепыхаться. С RAID1 - вообще самопочинится влет, а если у вас будет более обычный RAID, он при налете на десинк девайсов будет в полном ауте.

Может слететь транслятор. И тогда если вам данные нужны - вы пойдете в DR лабу. И отвалите кучу денеш. Потому что оно не то что совсем не читается, но выглядит интересно. И сами вы это не почините.

> Ну, а на счет флэша с дерьмовымми прошивками... НУ да, могут сдохнуть.

Покажите мне у кого прошивки без греха? Это стремные багованые глюкала. У всех. Ну вон самс, крупнейший (?) производитель флеша на планете. Жуткое глюкало в FW. Везде.

> Но тут даже HDD могут сдохнуть во время внезапного пропадания питания (запил поверхности,

Для современных HDD не характерно: при этом там просто автопаркова на рампу.

> так вообще продолб минимум 50G минфы (если очень повезет, а обычно
> - слет транслятора).

Это SSDшный failure mode вообще, изначально (анти)фича флешатины. А если кто хотел влезть в оба мира он и оба набора проблем получил.

> Чего уж тут. Речь идет о том, что нормальная ФС маленько по иному барьеры
> расставляет и данные на диск раскладывает

Вообще-то недеструктивность записей btrfs как раз обеспечивает выживаемость оных в случаях когда многие другие запиливаются насмерть и без плана Б. А хранение по дефолту 2 копий метаданных даже на 1 носителе (схема DUP) дает куда больше шансов при отклонениях от идеала. А есди у EXT4 ...цать мегов улетят нафиг - плана Б нет и если не понравилось то что вышло, что хотите то и делайте.

> (если они важны) в несколько копий. А не так, что бэкап суперблока один на устройство.

У btrfs 2 бэкапа супера на девайс + по дефолту DUP метаданных даже на 1 устройство или RAID1 на >1 устройства (схема данных и метаданных могут отличаться). Если девайсов много, можно для метаданных RAID1C3/C4 (3 или 4 копии) юзать вообще.

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

207. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (151), 08-Янв-24, 20:28 
> Бывает всякое. Да, накрути ECC-память, диски с суперконденсаторами,
> да строго соответствующие спецификации и т.п. А надо, чтобы работало на обычном
> консьюмерском железе, которое исправное, но вот может не успеть, например,
> сбросить кэш при выключении при некотрых специфических условиях.

Глядя на Unsafe shutdown count == 102... ну, вот, за 102 попытки на этом SSD не сдох вроде :). А должен? Тем не менее - если буфера не скинули, команду на шатдаун накопителю тоже поди не послали. А так и весь eraseblock/erase group можно профачить, а то и таблицы транслятора.

И ни 1 ФС не готова к тому что слетит 64-128 мегов или сколько там erase group - который in flight когда вы там питание грохнули без подачи команды на шатдаун. Имеет право слететь без подачи такой команды - накопитель сам внутрях GC и проч тоже гонял.

> И то, что ФС потеряла b-дерево > и не смогла обратитсья к предыдущей его копии -
> это, таки, настораживает, бо в суперблоке должна быть ссылка и на старые
> и на новые данные.

А там что, RAID не было и даже DUP? Что за ошибка была? В суперах ссылка на последнее консистентное состояние. Но есть опции монтирования с попыткой заякориться за другие деревья на случай если хрень все же почему-то случилась. Это не есть нормальная ситуация, потому - мануально.

> "не проснулся" в данном случае означает, что он тупо завис после выхода
> из гибернации на картинке логина.

Я бы дал 50/50 что в RAM какая-то труха образовалось.

> И это не говорит о том, что RAM порушилась, т.к. после реинсталла
> ОС и на другой ФС этот же ноут отработал ещё 5 лет без единого сбоя,
> пока его кофе не напоил.

А это все в каком году и с каким кернелом было? Я просто про более-менее современные версии, скажем, ядра 6.x - а что там в 2.6.32 было я и не знаю, ибо в курсе что бесплатный сыр достается второй мышке, надо просто подождать :)

> Я же не зря выше оговорился, что проблемы у нее будут на
> "не дорогом консьюмерском" оборудовании.

Я ее гоняю на самом разном хардваре. Очень интересно, где обещанные проблемы?

> Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных,

Есть опция монтирования usebackuproots, вообще-то.

> записанную ранее и не может отреплеить журнал.

У нее почти нет журнала в привычном понимании, так, зачатки минимальные. Но если с ними проблемы, опять же - опция монтирования есть чтобы забить на реплей.

А в целом - cow никуда прошлые состояния не девает и при крахе по сути просто игнорит то что записано но - "указатели еще не перевешены" и этого как бы никогда не было. Неплохо работает вроде.

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

В btrfs записи недеструктивные, на минутку. Так что красивая теория но не про btrfs.

> кто понимает структуру этой ФС на уровне разработчиков - все бы оттуда вытащилось.

Да там небось как максимум надо было nologreplay и/или usebackuproots. Правда кто вас знает в каком это году...

> Это разница в подходе. Когда ext4 обнаруживает, что crc в метаданных не
> совпадает - оно начинает ругаться и прекращает всческую запись,

А на данные - он класть вообще хотел. С прибором. Основной регион - это данные. Более того, если метаданные не прочлись, ну там бэд или труха с накопителя, EXT4 ловит нехилое фаталити. Плана на этот случай совсем нет. И никаких копий метаданных тоже. Так что урон очень даже.

Btrfs даже с 1-девайсной конфигой хранит метаданные в схеме DUP, и чаще всего может вынуть их из второй копии. На этом фоне EXT4 - как бы это сказать? Они CRC там не от хорошей жизни сделали, но в случае RAID например они не смогут умно читануть вторую копию с исправной версией. Если райд diverged - что хотите то и делайте, во! Хитрый план! Но мне btrfs'ный план ака читануть вторую копию, починить из нее убитую - нравится больше. Кенту этот план тоже по вкусу.

> BTRFS в аналогичной ситуации проблем не заметит,

Да неужели? У него чексумы на вообще все, и на метаданные, и на данные.

> т.к. она их замечает только при очередном scrub.

Булшит, оно замечает (и даже чинит в фоне, если есть откуда) при любом чтении.

> Больше секса без видимого результата. Могу и по пунктам, но ext4 _значительно_
> проще в силу того, что btrfs всё же CoW.

Он не только проще - но и фатальнее при отклонениях от идеала. Избыточности нет, возможности умно ей пользоваться даже если RAID и был (прицельно перечитать блок метаданных с второй копии) - тоже нет. Это динозавр. Плевавший на данные пользователя - чексум данных нет, а полный журнал конечно есть но это для совсем мазохистов.

Никто более не проектирует ФС по этому паттерну. Его время вышло.

> И сырые данные с BTRFS восстановить почти не возможно, если будет утеряна
> структура ФС в силу CoW (упс).

Чтобы вообще совсем снести весь btrfs в ноль надо нехило потрудиться. У него три копии суперов по зело разным смещениям, возможны разные точки входа в деревья, офлайн-вычитывалка в комплекте которая умеет вот это вот. И если даже ЭТО не смогло ничего нащупать - так там наверное и от данных мало что уже есть.

И мне даже неудобно говорить что вычитка путем полного скана поверхности требует дофейхоа времени, дает много битых файлов, ведет к потере имен, и эта операция уж точно не для казуалов. А датареки за это уже прилично обдерут, т.к. довольно неудобный случай.

> Чето в моем случае этих старых версий деревьев чего-то как-то не оказалось,

А вы usebackuproots пробовали?

> а вручную дигать по диску в поисках копии данных я как бы это...

В команду "btrfs" встроен кроме всего прочего офлайн парсер на совсем тухлый случай. Man btrfs-restore в общем. Не, на ext4 такого тула нет. Во всяком случае штатно и под линух. Под винду на нтфс сторонние утили с своим парсером - да, но это сторонние проприетарные коммерческие проги. А тут прям в родном тулките ФС. У кента кстати этого тоже нет вроде, как минимум пока.

> Данные столько не стоили. Правда теперь у меня появился
> не только бэкап, но и проверка его содержимого, ага.

А бэкап так то не лишний в любом случае. Should never happen как бы да, а бэкапы как бы вот. Потому что случаи бывают разные.

>> Если хардавар не выходит из хибернации - он не в порядке
> Софт безгрешен?

Иногда даже бывает сложно понять кто и что. Если скажем при программировании DMA автомата в адресах облажались и прострелили кернелу мозг - это софт или хард? Так можно было, проверено как минимум нвидией, и файлухи ЭТО выносит на ура :). Вон там нвидия поубиваля хомякам их EXT4 и XFSы какой-то относительно недавней версией драйвера.

> Да. В ядре 6.7 менялись некоторые механизмы, ога. Отсюда и проблема была,
> хи хи. И хардварь конкретно в данном баге ну вот вообще не при делах.

Это тоже случается. Я в контексте btrfs такое же примерно выловил и помог замочить пару ядер назад - но btrfs вообще попался только потому что рефактор его зацеплял. Вероятно и других цепляло - просто у меня были конкретные тестовые конфиги под -rc ядра где это вылезло я и отпинал бтрфсников, они доперли что это к mm/ и попинали их. Так клевый датакарапшн не прилетел на ваши бошки в энных случаях. Хотите мне еще рассказать что бывает? :)

>> Я не понимаю почему это недоразумение - замечательно.
> В сравнении с btrfs у него хотя бы аналог RAID5 работает

Ага, тут недавно была новость как там что на самом деле работает. Там где про разрушение данных если быстро делать копии копий. Заодно всплыло немало интересного как господа фичу рефлинков выкатили - включив по дефолту, для тестов на хомяках. Ну и тестанули. Test failed ахнул гентушник билдивший go.

> умеет в slog и L2ARC, оно ЗНАЧИТЕЛЬНО надежнее btrfs by design.

Нехило бы это громкое заявление технически обосновать. Особенно учитывая что недавно у господ вышел сочный факап по линии их чудных кешей. И можно я скажу что Кент кеширование на SSD намного вменяемее продумал чем ZFSный бред?

> Но формат там весьма сложен, да.

Он не просто сложен - я так понимаю что он супертормоз и это вытягивают заливанием гигазами оперативы. Не вижу с чего этим структурам быть быстрыми. Это не bcachefs. И даже не btrfs. Какая-то полублочная муть. На которую, вот, рефлинки цать лет пытались, а когда смогли, крякнул кеш.

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

Я немного сравнил с btrfs - и каких-то радикальных улучшений так с наскока не увидел. В принципе понимаемо - кенту пришлось идти на компромиссы для майнлайнинга, потом отыграет часть.

> Записываю: btrfs безгрешен и ошибок в алгоритмах иметь не может.

Может ессно. Проверено ZFS'ом недавно :). Но даже после такого фееричного обтекания вашего фетиша сватать его вам стыд глаза не ест...

> Ещё раз: даже если это был @ram corruption@ - данные должны быть восстановимы. Всё.

Откуда бы это все следует? Ну и в btrfs возможностей с этим потрепыхаться и читануть таки либо маунтом либо офлайн парсером - сильно больше чем в среднем по больнице. А выгрызать их фотореками всякими - удовольствие сильно ниже среднего. Как практикующий этсамое грю.

> ext4 имеет чексуммы метаданных, что почти сразу скажет о проблемах.

Пардон, но
1) Он нихрена с этим не сделает уже.
2) Он не парится насчет данных. А метаданные мне нужны только для доступа к данным и самоценности не имеют. И я не ок с отсутствием чексум данных, как угодно.

Примерно 99% проблем с integrity в случае btrfs - на регионе ДАННЫХ было отловлено. Так что мне трогательная забота данных - не приболела, извините. Как и весь динозаверский дизайн с фиксированой аллокацией инодов.

> Кент вон на это посмотрел и в планах коды рида-соломона прикрутить.

И оно как бы похвально, вопрос в том не познакомится ли он с комбинаторным взрывом...

> метаданные останутся в RAID0, ибо в документации это написано, но недостаточно очевидно.

Я только 1 случай знаю когда btrfs сам умничать может - если 1-девайс с DUP до 2 добавить, метаданные будут RAID1 тогда. Но это внезапно может проблемы создать, если план был второй девайс вынуть. Такая автоматика может сделать мозг. И таки совершенно валидно RAID0 для данных и RAID1 для метаданных, так метаданные будут выживать сильно лучше, а если у части данных избыточности не было - ну, досадно, но урон небольшой.

> Тваю за ногу... bcachefs родилась из bcache, а не btrfs.

Если описывать его в 2 словах это выглядит примерно как гибрид первого со вторым. Часть кода похоже вообще скопипастили 1 в 1 - обработчик "same extent" у обоих был подозрительно похожий. Дальше он конечно в свои кишки по другому уже.

> И да, число копий метаданных настраивается, но не так, как в btrfs.

Не так - но в целом идея довольно похожая. И опять же - вот - разное число копий вполне валидною. А аллокация в buckets имеет что-то общее с chunks, хотя и отличий - есть. Такое ощущение что они пытаются конвергировать к чему-то - заходя с разных сторон.

> И число данных тоже. Там каждый девайс имеет параметр durability.
> Т.е. при создании ФС указываешь число реплик для данных и метаданных и дальше
> при добавлении девайсов просто указываешь ему durability.

У btrfs унутрях в чем-то похожая идея. Для данных и метаданных есть дефолтовая схема хранения для их блоков. И в конечном итоге RAID1 это "2 копии". С3/С4 - 3 и 4 соответственно.

И мое частное мнение - кент с Durability хлебнет горя, когда умные клавы доверятся черти каким райдам, и тут окажется что обе копии было там - и это не прозрачно для ФС - так что re-read копиии с целью фонового репайра - "агащас!" и вот на ка тебе заваленый пул, золотая рыбка, ибо нефиг такое делегироватоь всякой мутной ср@ни c уровня ФС. Правда этот прострел пяток на усмотрение стрелков, но кмк - прострелы будут.

> Ты даже можешь raid аппаратный подсунуть и указать durability ему выше единицы,

Ага. А потом попробуй оттуда re-read если что-то все же ну вот не прочлось... КМК кент таки познакомится с теми кто на "кульной фиче" налетит.

> У btrfs же какаой-то секс с профилями и прочим При том - не всегда очевидный.

На самом деле примерно то же самое по смыслу. И кент секса тоже добавит с RAID56 и прочими ридсоломонами постепенно.

> Не надо говорить, что кто-то у кого-то передрал. Смиритесь, что некоторые вещи
> где-то могут быть реализованы лучше, а где-то хуже.

Кент мог смотреть на 2 дизайна - и ессно имел все шансы учесть их траблы. Но дело в том что он уже заметил что некоторые решения вон там были не просто так. Как с backrefs... :). И вот уже оказывается что Кенту и самому скорость операций менеджмента и GC - "не очень". Зато backrefs не передрал. Пока. Это разгоняет перфоманс - но при желании отменеджить эту экономию захочется проклянуть. Ибо теперь вынуть девайс - уже не так уж просто и быстро.

> Если я хочу вынуть девайс из рейда - должно быть максимум две команды
> (отправить его в статус fail, а после вынуть).

Кому должно? С чего? RAID1 вообще не должен штатно работать с 1 девайсом. Только degraded. В таком виде можно его и совсем без команд получить, выдернув накопитель.

> mdadm, LVM, ZFS это позволяют. И даже bcachefs.

Btrfs тоже. Я даже именно этот сценарий пару раз делал. А ваша вкусовщина - это ваша вкусовщина. На мой вкус вы и возитесь с вашими LVM, mdadm и ZFS. Я же предпочту без этого секса. И да, кентовская штука управляет местом "примерно как btrfs". Т.е. для нее не проблема подоткнуть или вынуть девайс и получить +N места, из-за аллокации bucket'ами. По общей логике это именно btrfs косплеит. Да, есть отличия, и все же. Оно сможет в ту же прелесть ненапряжного расширения места и ремува девайсов. Без делания мозга выравниванием и размерами. В отличие от блочных уродцев. Это то что у него как в btrfs.

> Без шаманств с профайлами метаданных. Почему в btrfs это сложнее?

Да там горе от ума походу. Ну, бывает :). Мне похрен ибо столь странная операция была нужна пару раз в жизни. При том вообще в научных целях - посмотреть, смогу я под живой системой системный девайс сменить без отвалбашки на горячую?! Мне была интересна технологическая валидация такой возможности.

Это на самом деле дает довольно интересные технологические возможности фикса системы в режиме нонстоп. Как в анекдоте где хирург оперирующий на сердце садится в авто, заводит, и говорит мужику в автосервисе - мол, хочешь получать как я? Тогда чини авто вот так, как я твое сердце. Мне было интеерсно прочекать технологическую возможность смены накопителя под ОС без ее стопора. С btrfs этот фокус прокатил.

> Да да да. Всё просто, когда знаешь. Мне вот ZFS сейчас проще кажется ;)

А мне он нафиг не упал с его внемайнлайн проблемами и античным дизайном. Штука кента - оно в майнлайне и "Gen3" идеи, совсем другой разговор.

> Общие идеи - они впринципе проистекают как раз от ZFS, если уж так судить,

Частично - да. Но у ZFS вроде как раз и нету такой "пофайловой" аллокации места на девайсах, когда можно абы какие девайсы абы как добавлять-вынимать и там аллокация места "as needed", с пофигом на выравнивания и размеры девайсов. Это довольно круто придумано и делает менеждмент простым и ненапряжным. И это уже не блочный райд, ближе к "файловому", грубо говоря, это -  решение уровня аллокатора ФС, как вон то раскладывать.

Для меня это довольно четкая граница водораздела по технологиям. Либо тупой блочный RAID, либо такая вот динамическая аллокация без прогрева мозга. В ZFS разве это было?

> btrfs все же корпорации делать пытались, а не какой-то перец в одно хлебало.

Поэтому архитектуры там все же побольше. Зато у Кента задора и упорства на троих хватит. И он уже мог смотреть на чужие траблы. Это ценный козырь, так что ряд проблем btrfs он обошел. Но вероятно получит ряд других.

> Эээ... Оно их убьет наповал, если там writeback. В остальном - ничего он не сломает.

В случаше bcachefs - ему статус реплик по накопителям - и факапы их чтения - виднее будут. А на фс подпертым bcache - они феерично сыпятся когда bcachе выгружает им баааальшой блок трухи с кешового накопителя. От такой диверсии ФС могут развалиться вдрызг. И я видел эн таких случаев. Btrfs'ники обычно замечают подарки по ору в логах ДО того как все совсем уж профачится, а остальные - вот как повезет.

> именно смерть ФС при повреждении и подразумевает.

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

А если работать на блочном уровне как bcache - это знание урыто на стыке уровней, нельзя осмысленный re-read и self heal сделать с другой копии вот так по простому. ФС с полными чексумами типа btrfs могут еще попытаться что-то изобразить, но получится ли это - без гарантий ибо оно не контролирует IO с копиями и успех этого маневра ниоткуда не следует. А вот если оно явно рассматривает кеша как реплику, и запрошено более 1 реплики, окей, оно сможет вынуть другую реплику вместо осыпавшейся - и проблемы как бы и нет. Ибо оно уже таки как раз может контролировать процесс.

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

159. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (154), 08-Янв-24, 18:29 
В продакшене в основном применяют ext-ы и xfs. Навороченные ФС в первую очередь нужны для бедных.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

396. "Релиз ядра Linux 6.7"  +/–
Сообщение от Аноним (151), 10-Янв-24, 15:16 
> В продакшене в основном применяют ext-ы и xfs. Навороченные ФС в первую > очередь нужны для бедных.

А когда фйэсбук обнищать успел, не подскажете? Цукерберг тоже вместе с ним?

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

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
Добавить, Поддержать, Вебмастеру