No. ext4 checksums its metadata (the superblock, inodes, directory blocks, bitmaps and the journal), but it does not checksum the contents of your files, so there is nothing for it to “scrub”. If you want to know whether file data has silently changed on an ext4 disk, you have to keep your own checksums and compare them, or move the data to a filesystem or block layer that checksums data for you.
Disclosure: I’m Inna Hall, co-founder of TimeBinder, a browser-based timestamping tool. This guide mostly covers free Linux tools; TimeBinder only comes up at the end, for one specific use.
Table of Contents
What ext4 actually checks
Modern ext4 filesystems are created with the metadata_csum feature switched on. You can confirm it with sudo dumpe2fs -h /dev/sdXN | grep -i features. With it, ext4 stores a CRC32C checksum for each metadata structure and checks it when that structure is read. e2fsck -f will also check them all in one pass.
That protects the filesystem’s own bookkeeping. It does not cover the bytes inside your photos, archives or databases. If a data block flips a bit on disk and the drive’s own error correction does not catch it, ext4 will hand back the damaged data without complaint. There is no ext4 option to force a data checksum calculation, because the checksums were never stored.
Build your own scrub with a SHA-256 manifest
For a folder of files that rarely change (photo archives, backups, ISOs, project snapshots), a checksum manifest is simple and works on any filesystem.
- Create the manifest once:
cd /data/archive && find . -type f ! -name SHA256SUMS -print0 | sort -z | xargs -0 sha256sum > SHA256SUMS - Keep a copy of
SHA256SUMSsomewhere else too, so damage to the disk can’t take the manifest with it. - To “scrub”, run
sha256sum -c --quiet SHA256SUMS. Only files that fail or are missing get printed. - Run it from cron or a systemd timer every month or so, and after any move to a new disk.
- When you add files on purpose, regenerate the manifest so new files are covered.
Reading every file forces the drive to read every data block, which also gives the drive a chance to find and remap weak sectors. Check smartctl -a afterwards for reallocated or pending sectors.
If the folder changes a lot, a manifest gets noisy. Tools such as par2 add recovery data as well as detection, and backup tools like restic and Borg verify their own repository contents with restic check --read-data or borg check --verify-data.
Options that checksum data for you
- Btrfs checksums data and metadata.
btrfs scrub start /mntreads everything and reports mismatches, and with RAID1 or DUP it repairs from the good copy. - ZFS does the same with
zpool scrub, and repairs from redundancy where it exists. - dm-integrity (set up with
integritysetup, orcryptsetup --integrity) adds per-sector checksums under any filesystem, including ext4. Reads of corrupted sectors then return an I/O error instead of bad data. It costs some write speed and space.
Detection is not repair. Without a second copy, any of these will tell you a file is bad but can’t fix it, so a tested backup still matters most.
What a timestamp does, and doesn’t, do
A manifest tells you whether files match the hashes you recorded. It can’t show when you recorded them, and anyone with write access can regenerate it. That rarely matters for bit rot. It does matter if you may later need to show someone else that a file set existed in a given state on a given date, such as source code, research data or design files.
For that, you can timestamp the manifest itself. With TimeBinder the file is hashed with SHA-256 in your browser and never uploaded; the hash is anchored to the Bitcoin blockchain and you get a Proof of Time Certificate. Later, anyone can check that the manifest existed no later than that date and still matches its fingerprint. It does not show who made the files, and it does nothing to detect or repair corruption. Our guide to proving source code existed before a date walks through that use.
You can compute a file’s SHA-256 in the browser, without uploading it, with our free SHA-256 file hash checker. It gives the same result as sha256sum. For the built-in commands on each system, see how to check a SHA-256 checksum on Windows, Mac and Linux.
The free plan includes 1 Token a month, and one TimeBind covers up to 10 files. Paid plans are on the pricing page.
Frequently Asked Questions
Does e2fsck check file contents?
No.
e2fsck -fchecks metadata and its checksums. It can’t tell if the data inside a file has changed, because ext4 keeps no data checksums.Is a SHA-256 manifest overkill for bit rot?
Not really. A faster hash would also catch random corruption, but
sha256sumis installed almost everywhere, and the same manifest is useful if you ever need to show the files weren’t altered.Should I switch from ext4 to Btrfs or ZFS?
If you want automatic detection and you have redundancy for repair, they’re worth considering. If ext4 works for you otherwise, a manifest plus good backups covers most needs.
This article is general information. Commands were checked against current e2fsprogs, coreutils and btrfs-progs documentation on 28 October 2026.







