>В нормальном железе с безглючным 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 - ну... таки здесь как раз тот случай, когда сам по себе тип кэша именно смерть ФС при повреждении и подразумевает.