As a general rule of thumb external journaling on ext4 / ldiskfs type file systems can and will greatly improve overall write performance. This is due to the fact that you’re off loading small (4K) writes to an external disk or array of disks. Couple that with the fact that these writes are linear and do not require you to move the heads around on the primary data target, great gains can be achieved (especially when performing sequential large I/O writes).

So this is all good right? Faster more optimized writes and the safety of having a journal, tracking all writes in the event of unexpected storage target failure or outage.

Except theres a problem… If your journal device experiences some kind of failure event, which results in journal record corruption or in-transit memory/CPU based errors things can go from good to very very bad quickly.

This is because, upon mount (either clean or unclean shutdown of the file system) the journal record is blindly replayed, regardless as to content. This means that if you have a corrupted transaction record within your journal, or the transaction record is corrupted in-flight (due to memory or CPU error) you are at risk of severe file system damage and likely data loss.

There is a solution, this is to either avoid external journaling (which only partially addresses the issue) or better, enable the journaling checksum feature (journal_checksum). This will go a long way to preventing corrupted data from reaching your file system and hopefully ensure that the file system structure remains undamaged.