Recovery methodsTechnical

ext4 Superblocks, Inodes, Extents and Journal

ext4 recovery can lean on redundant superblocks, inode tables, allocation bitmaps and extent trees independently of each other — and its JBD2 journal restores structural consistency, not a historical backup of user files.

The block-group model

Linux kernel documentation describes ext4's global structures as a superblock, block group descriptors, a block bitmap, an inode bitmap, an inode table and a journal, with dynamic structures — inodes, extent trees, directory entries and hash-tree directories — built on top of them. Simplified, the chain runs from the superblock through block-group descriptors, into block and inode bitmaps plus inode tables, into inodes, into extent trees, and finally into data blocks. This gives a clean, non-NTFS, non-APFS example of the same general principle: metadata-aware recovery works by walking these structures directly, not by trusting whatever the active directory tree currently shows.

Backup superblocks are structural redundancy, not full backups

Kernel documentation states that ext4 can maintain redundant superblock and group-descriptor copies depending on which filesystem features are enabled; with the sparse_super feature, copies exist only in selected block groups rather than in every group. Primary superblock damage therefore does not always destroy the filesystem's geometry information, and backup superblocks can help reconstruct size and block-group parameters — but blindly running a repair tool against the wrong backup copy can still write a large amount of metadata based on an incorrect assumption. Backup superblocks are structural redundancy, not a complete backup of the filesystem's contents.

Inodes describe files; directory entries only provide names

An ext4 inode holds a file's metadata and its block or extent mapping; a directory entry only maps a name to an inode number. As on NTFS, name and file-metadata object are not the same thing: a directory entry can be missing while the inode, its extent tree and its file content all survive. A metadata-aware recovery tool can sometimes reconstruct considerably more of a volume than plain directory traversal shows.

Extent trees carry fragmented and large files

Modern ext4 commonly uses extent trees rather than long arrays of individual block pointers, with each extent describing a contiguous logical range mapped to physical blocks. If an extent tree is damaged, the underlying file blocks may still physically survive while their logical ordering becomes uncertain — leaving carving able to recover only recognizable fragments or contiguous portions rather than the whole reassembled file. This is one of the clearest illustrations on the whole site of why filesystem metadata is worth more than file signatures whenever it survives.

HTree directory indexing is not file content

Large ext4 directories can use hashed-tree (HTree) indexing, documented in the Linux kernel's directory-entry documentation. Corruption of that indexing structure can make files difficult to enumerate through normal directory listing while the inodes remain valid, the blocks remain allocated, and the file extents remain fully intact — reinforcing the cluster-wide point that directory visibility is only one metadata layer among several.

JBD2 protects consistency, not user-data history

ext4 uses the JBD2 journal specifically to avoid leaving filesystem metadata halfway through a transaction after a crash. A journal transaction is structured as a descriptor, the data or metadata blocks it protects, and a commit record; without a valid commit record, replay discards the transaction rather than applying it partially. By default ext4 journals metadata rather than all user data; data=journal can journal both, data=ordered is the common default-style model, and fast-commit modes can store minimal deltas. See Filesystem Journals and Crash Consistency for how this same distinction plays out on NTFS.

Orphaned inodes and metadata checksums

ext4 tracks orphaned inodes — those whose links have been removed but whose data has not yet been fully released — as part of its own crash-recovery bookkeeping, and can carry metadata checksums where the feature is enabled to help validate structures before trusting them. Both are useful evidence for reconstruction, but neither substitutes for imaging the source before running a repair pass that could alter or discard them.

Practical rule

Treat ext4's superblock, bitmaps, inode table and extent trees as independently useful evidence. A damaged directory tree does not mean the inodes and extents beneath it are gone.