>>BTRFS хороша и стабильна.
> Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,

Люблю экспертов опеннета, всегда блеснут экспертизой...
1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет parity (RAID5/6, не рекомендуется, особенно второй).
2) CRC32 довольно хорошо ловит "битовые ошибки" типичные для факапов сторажей и глючного железа.
3) Если CRC32 мало под ваши требования есть xxhash, и даже sha256/blake2s - если надо ну вот реально неубиваемый хеш который хрен словит коллизию даже на петабайтах. Но если у вас хеш стресстестится - это наверное повод задуматься о смене гнилого железа так то.

> есть не хилый шанс не починить фс.

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

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

Сразу видно эксперта который btrfs видел только на картинке. И то не факт.

> мере приделали рабочий костыль_это я про дополнительное место для метаданных) но
> отсутствие рабочего fsck уже достало...

Для меня это вообще ломовая фича в ситуациях где некому any key жать, оно просто работает, отклонения от идеала - парирует из другой копии. А отвечать на тупые вопросы на встраиваемых системах, да и серверах ВНЕЗАПНО, НЕКОМУ.

Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными вполне может и скопытиться или потерять довольно много данных. Plan B на этот случай - нет. И даже RAID1 в подобной ситуации может и не помочь, особенно если накопитель как сейчас модно вернет труху без отлупа IO error, что конечно подляна - но бывает вот.

> (Но очередь записи в схеме жёсткий диск + Флэш память у btrfs
> хороша,такого конечно в ехт4 нету и хрен сделаешь....)

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

Btrfs, bcachefs и ко читерят - идея cow в том что по сути журналом становится вся площадь. При этом более не надо переносить из журнала в основную область и вторая запись отпадает. К сожалению, это вызывает нужду в Garbage Collector ибо вечная история записей - все же сожрет место. И иногда надо все же подтирать. Такой подход приколен тем что при записи ничего не портится из существующего. А фикс консистентности делается ... простым игнором недописаного. Этого никогда не было - и все тут. Ведь все данные для предыдущего состояния - на месте. Отсюда и нужда в аллокации места для изменений. К метаданным это тоже применяется. Поэтому на btrfs всегда есть множество альтернативных точек входа для поыптки ре-парсинга. Это будут чуть более старые состояния, но возможно что нужный файл в нужном виде там был, а деревья этого состояния достаточно живые чтобы нужные файлы вынуть.