Как раз у журналируемых - гарантируется, что пострадают только те данные которые в этот момент писались на диск. Однако по факту - тут бывает по разному. XFS, скажем может и метаданные запороть, у ext3/4 тоже косяки иногда вылазят, хотя и очень редко.
У btrfs с этим еще немного лучше - там все операции записи атомарны. Т.е. если у нас идет запись в какойто-то файл, и питание пропало - после отката журнала файл окажется в том состоянии, как перед началом записи. Каши внутри, или просто чего-то записанного наполовину быть не может. btrfs так устроена - для этого служит механизм COW. Новые данные всегда пишутся в новый блок а не поверх старых, проверяются контрольные суммы, и только если все хорошо меняется запись в метаданных о том какие блоки принадлежат файлу. И уже только после этого старые блоки становятся свободными. Сами же метаданные присутствуют в двух экземплярах и запись туда идет не одновременно, что дает возможно всегда иметь последнее нормальное состояние FS. Правда в случае SSD по умолчанию метаданные на нем создаются в одном экземпляре для уменьшения износа (когда-то было актуально), но можно твикнуть в "стандартный" режим с двумя копиями. Минусы тоже есть - нельзя переписать файл если на диске не осталось места (т.к. сначала пишем новое, потом удаляем старое а не наоборот), и потенциально - фрагментация. Т.к. новые блоки выделяются постоянно для любой операции. Но тут неплохо справляется штатный механизм дефрагментации. А можно и вручную пройтись...
Можно, кстати и механизм COW выключить, причем даже для отдельного файла или каталога (это нужно, например, в случае образов виртуалок - чтобы тормоза и фрагментацию не плодить). Но в таком случае и устойчивость подобных данных снижается соответственно. Так что если, скажем, этот дятел сделал "оптимизацию" с отключением COW для всего диска...
. Проблема видимо настолько серьезная и так глубоко закопана, что придется искать до конца мой жизни. 