ext4

Identity

• Kernel module: Built-in (ext4 — no separate package needed)
• Userspace tools: e2fsprogs package (apt install e2fsprogs / dnf install e2fsprogs)
• CLI tools: mkfs.ext4 (alias: mke2fs -t ext4), e2fsck, tune2fs, resize2fs, debugfs, dumpe2fs, blkid, findmnt
• Config: /etc/fstab (mount options), no daemon config file
• Logs: journalctl -k | grep ext4 (kernel messages), dmesg | grep ext4

Key Operations

Expected State

• dumpe2fs -h /dev/sdXN shows Filesystem state: clean
• e2fsck -n /dev/sdXN returns exit code 0 with no errors reported
• Journal mode set (default: has_journal feature present)
• No bad blocks listed in dumpe2fs bad block count

Health Checks

1. sudo dumpe2fs -h /dev/sdXN 2>/dev/null | grep "Filesystem state" — should output clean
2. sudo e2fsck -n /dev/sdXN 2>&1 | tail -3 — exit 0 means no errors (must be unmounted or read-only mounted)
3. df -i /mountpoint — verify IUse% is not near 100%

Common Failures

Pain Points

• Must be unmounted for fsck: Unlike btrfs, ext4 requires the filesystem to be unmounted (or mounted read-only) for e2fsck. On live systems this means booting from external media for root filesystem repair.
• Reserved blocks default 5%: On a 4 TB disk that's 200 GB reserved for root. For pure data disks (non-root), set -m 1 at mkfs time or tune2fs -m 1 afterward.
• Inode count is immutable: Set at mkfs time (-i bytes-per-inode). If you run out of inodes (many small files: mail spools, container layers, package caches), you cannot add more without reformatting. Check early with df -i.
• e2fsck -y is dangerous on healthy filesystems: The -y flag answers yes to every prompt including destructive ones. Use only when you intend full automated repair on a known-dirty filesystem, not as a routine precaution.
• ext4 vs xfs for large files: xfs handles large files and high-throughput workloads better; ext4 is preferable for workloads with many small files (better directory indexing via htree). Neither is universally better — choose at mkfs time.
• Journal replay on mount: If the previous unmount was unclean, ext4 replays the journal automatically on the next mount. This is safe and normal, but dmesg will show recovery messages. If journal replay fails, the filesystem goes read-only.
• noatime is almost always correct: Default relatime still writes atime on first access after mtime changes. For high-throughput workloads, noatime in fstab eliminates all atime writes entirely.

References

See references/ for:

• ext4-options.md — mkfs.ext4, mount, and tune2fs options with purpose and when to use each
• docs.md — official documentation and man page links