> это у которой одна fs "works as intended","Works as intended" вполне документирована - делай бэкапы, отключай "оптимизацию" записи данных на диск (или не бери диски, которые в ответ на sync "врут", что они все записали, хотя на самом деле ... а ведь просто нужно было вовремя и дружно бить маркетологов арматуриной, когда они проталкивали эту пакость, вместо покорного подстраивания и вкорячивания квирксов) или отключай журнал или заимей УПС и будет тебе щастье.
Опять же, dump+restore прекрасно работает, в отличие от.
К тому, есть некоторые сомнения что чексуммы метаданных в журнале решают эту проблему сильно лучше, т.к. по умолчанию запись и в пингвине вроде как "ordered" (и зависит от этого) плюс журналируются только метаданные. Но целостность метаданных совсем не означает целостность самих данных.
Или вы хотели сказать, что лучше (потому что меньше знаешь -- крепче спишь) просто тихо портить данные (типа blq-mq) в любой FS, заодно превращая бэкапы в тыкву?
https://www.opennet.ru/keywords/ext4.html
[05.12.2018] Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, которая приводит к потере данных
[23.05.2015] Проблема с повреждением разделов Ext4 оказалась в md-raid0
[20.05.2015] В ядре Linux выявлены ошибки, приводящие к зависанию процессов и повреждению разделов EXT4
[05.04.2013] В Ext4 исправлена ошибка, которая потенциально могла привести к разрушению данных
[06.11.2012] Обновление ядра Linux 3.0.51, 3.4.18 и 3.6.6 с устранением нашумевшей проблемы в ext4
[02.11.2012] Выпущен патч для исправления ошибки в ext4, которая могла привести к повреждению ФС
[25.10.2012] Появившаяся в ядре Linux 3.6.2 ошибка способна привести к повреждению данных в ФС Ext4
А вот в простой, как валенок, UFS только "works as intended".
