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

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

И что делать при рассинхронизации копий - знает только шибкоумный алгоритм.

> А ext-ы что? Если бэд влезет под метаданные, там будет спасибо если не хексэдитор.

не, не будет. Будет пачка оторвавшихся inode, и скорее всего ты найдешь свои файлы в lost+found, может с потерянными именами и неправильной длинной. Сто раз проверено. Потому что ее писали как раз когда диски и память не шибко отличались надежностью. По факту надо очень-очень стараться, чтоб вообще увидеть что-то ценное попавшим в lost+found
total 588
-rw------- 1 user users 190946 Dec 26  2015 #3146740
-rw-r--r-- 1 user users  33156 Sep 22  2015 #3162003
-rw------- 1 user users 318722 Jan  6  2016 #3165803
-rw-r--r-- 1 user users  52401 Apr 12  2018 #3286995
ну так как-то вот.

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

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