> Обычно цель всё же не живучесть и способность загрузиться на убитой флешке,

Как по мне - это вполне хорошая и правильная цель, экономящая немало нервных клеток. И вообще Early Warning задолго до факапа - это хорошо и правильно.

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

В этом плане EXT4 довольно неплох. Однако btrfs с его тулкитом офлайн вычитывания на мой вкус выглядит нормально.

> Чтобы часть файла оказалось старой и всё было перемешено, я с таким не сталкивался
> если честно, хотя использую data=writeback всегда.

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

> Такая вероятность имеется при повреждении метаданных из-за отключённых барьеров.

Метаданные могут повредиться и просто потому что стораж так решил. Чексумы как минимум сообщат нам об этом. Независимо от того решило ли фирмваре сообщить наверх IO ERROR или просто выдало наружу какую-то труху (бывает и так и сяк). И это довольно полезно. Потому что потуги парсить откровенную труху ни к чему хорошему не приводят.

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

Я нечто такое пробовал, для inline файла. Ничего ужасного. Для активного файла вопит про CSUM ERROR, для стертого варианта вообще до балды (GC при подгребании видимо уже не парится такими мелочами).

> Ничего не получится, всё дерево рассыпается и ошмётки никак
> не собрать. Выглядит опасно и непредсказуемо.

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

Кстати самый крутой "real world" дестрой btrfs который я встречал - флеха тупо повисла при записи. Видимо на уровне контроллера. При передергивании она ... профакала 2 из 3 суперблоков btrfs. Однако сие довольно просто чинится и таки 3-я копия выжила. Я думаю что контроллер потерял запись eraseblock-а, встряв в середине операции. Это типично несколько мегов профаканых данных. Хотя может и хуже оказаться - если оно таблицы трансляции апдейтило, карта/флеха рассыпется в адский паззл.