The journal contains information that can be replayed on a crash to hopefully avoid an file system check and repair to make the file system consistent. It's int

The journal contains information that can be replayed on a crash to hopefully avoid an file system check and repair to make the file system consistent. It's intended to address how long fsck can take as file systems get bigger. It has nothing to do with data integrity per se. Recently ext4 adds journal and metadata checksums (feature metadata_csum) to detect corruption, but data is not checksummed by the file system. Each drive sector is checksummed. The expectation by ext4 (and XFS) when it comes to data integrity is that it's the responsibility of the hardware or some other layer, like dm-integrity. The data integrity problem is you don't have a way of unambiguously determining data integrity. You have to trust the hardware. Obviously that's good enough most of the time, but it can transiently misstep without outright failing: bit flips, torn or misdirected writes. By the way, make sure you check for timeout mismatches if you're using consumer drives. Affects Btrfs, mdadm and LVM raid, and I assume ZFS on Linux. https://raid.wiki.kernel.org/index.php/Timeout_Mismatch https://raid.wiki.kernel.org/index.php/Timeout_Mismatch