ext4 (Fourth Extended File System)

ext4 is the fourth generation of the Extended File System family that traces back to 1992. The lineage is short and important: ext (1992) was Linux’s first dedicated file system, replacing the Minix file system that early Linux versions had borrowed. ext2 (1993) was the long-running default through the 1990s. ext3 (2001) added journaling without changing the on-disk format, so existing ext2 file systems could be upgraded in place. ext4 (merged into the Linux kernel as stable in October 2008 with kernel 2.6.28) is a deeper rewrite, modifying core data structures while keeping backward compatibility with ext3 read access.¹

The defining property of ext4, like every Unix file system, is that everything is referenced by an inode. An inode is a small fixed-size data structure (256 bytes by default in ext4, up from ext3’s 128 bytes) that holds a file’s metadata: size, owner, group, permissions, timestamps, and pointers to where the file’s data lives on disk. The directory entries that you see when you list a folder are just (filename, inode number) pairs; the actual file metadata lives in the inode table.

Block groups: the on-disk structure

ext4 divides a volume into block groups, each containing a fixed number of blocks (typically 32,768 with the default 4 KB block size, so each block group covers 128 MB). Each block group has the following structure:²

• Superblock (first block group only by default, with backups in selected later groups). Holds the most critical file system metadata: total inode count, block count, block size, mount count, last check time, file system features. The superblock is replicated at predictable offsets throughout the volume; mke2fs tells you where the backup superblocks live when you create the file system.
• Group descriptor table. Describes every block group on the volume, with the location of each group’s bitmaps and inode table. Replicated alongside the superblock for redundancy.
• Block bitmap. One bit per data block in the group; 0 means free, 1 means allocated. This is where ext4 tracks which blocks are in use.
• Inode bitmap. One bit per inode in the group; 0 means free, 1 means allocated.
• Inode table. An array of inodes, indexed by inode number within the group. Each inode is 256 bytes by default.
• Data blocks. Where files actually live. Most of the block group’s space is data blocks; metadata structures take a small fraction.

Extents: the ext4 allocation upgrade

This is the biggest on-disk change from ext3 to ext4. ext3 tracked file location with block-pointer indirection: each inode held 12 direct block pointers, then 1 indirect pointer (pointing to a block of pointers), 1 doubly-indirect pointer, and 1 triply-indirect pointer. Files larger than ~50 KB required indirect blocks; files larger than ~50 MB required double-indirection. This created significant metadata overhead and excessive seek operations on large files.³

ext4 replaced the indirect-block scheme with extents. An extent is a contiguous run of blocks described by a starting block number and a length. A 1 GB file that happens to be contiguous on disk is described by a single extent (start_block, 262144) instead of thousands of indirect block pointers. The inode itself holds up to 4 extent descriptors inline; files with more extents (heavily fragmented files) use an extent tree where additional extents are stored in dedicated tree nodes.

The recovery implications are significant: extent metadata is more compact, so a single damaged extent can take out a larger range of file content than a damaged indirect block on ext3. But extents are also more efficient to scan for recovery purposes, which is why modern recovery tools like extundelete and ext4magic specifically target extent reconstruction.

Journaling modes

ext4 inherited journaling from ext3 with three configurable modes:⁴

• writeback mode. Only metadata is journaled. File data may reach disk before or after metadata, in any order. Fastest mode but worst crash safety: a crash can leave files with stale data referenced by new metadata.
• ordered mode (default). Only metadata is journaled, but file data is forced to disk before the corresponding metadata is committed. After a crash, journal replay brings metadata to a consistent state, and the file data referenced is guaranteed to have already been written. This is the right balance of safety and performance for most use cases.
• journal mode. Both metadata and file data are journaled (every byte written twice). Slowest mode but safest: after a crash, journal replay restores both data and metadata. Useful for write-heavy workloads where data integrity matters more than performance.

The journal itself is stored in a dedicated inode (inode 8) and its content is exactly what tools like extundelete read to reconstruct deleted files. This is the key recovery insight for ext4: the journal contains old copies of inode metadata before files were deleted, and recovery is largely about extracting and parsing the journal.

HTree directory indexing

ext4 directories are themselves files (just with a directory inode type), and their content is a list of (filename, inode_number) entries. For small directories this works fine: a linear scan finds the entry quickly. For large directories, ext4 builds an HTree (hashed tree) index automatically. The HTree is a specialized B-tree that hashes filenames and stores them in tree nodes, allowing O(log n) lookup even in directories with millions of entries.

Linux kernel 4.12 added the large_dir feature that extends HTree to 3 levels, supporting directories with up to 6 billion entries. For consumer use this is irrelevant; for server workloads with massive directories (mail servers, content stores), it’s essential.

ext4 was a major upgrade over ext3 not just in scale (volume and file size limits) but in how it manages allocation, performance, and reliability. Many ext4 features are invisible to users because they “just work” silently in the background.⁵

Delayed allocation

This is the feature that surprises Linux users most when they first hit it. ext4 doesn’t allocate disk blocks immediately when a file is written; it buffers the data in memory and decides where to put it on disk later. The benefit: the kernel can see the full picture of what’s being written and place blocks contiguously, reducing fragmentation. The cost: a crash between the write and the allocation can lose data that the application thought was on disk.

Famous example: KDE 4.0 had a bug where configuration files were truncated during crashes because ext4’s delayed allocation left the writes buffered. ext4 added auto-detection (since kernel 2.6.30) for the common rename-to-replace pattern that applications use for atomic file updates, forcing immediate allocation in that case. The lesson for application developers: call fsync() if you actually need data on disk; don’t rely on the file system to do it for you.⁶

Multiblock allocator (mballoc)

Where ext3 allocated blocks one at a time (calling the block allocator for each block), ext4 allocates multiple blocks in a single operation. Combined with delayed allocation, this lets the file system find an optimally-sized contiguous run for the entire write at once. Significantly faster for large file writes and significantly less fragmentation in practice.

Metadata checksums (since e2fsprogs 1.43)

ext4 added optional checksums on metadata structures (superblock, group descriptors, inodes, directory blocks) starting with e2fsprogs 1.43 in 2016, and they became default for new file systems shortly after. These are not as strong as ZFS or Btrfs’s per-block data checksums, but they catch corruption in critical metadata before it propagates. Use tune2fs -O metadata_csum to enable on existing file systems.

Journal checksumming

The journal itself is checksummed: each transaction in the journal includes a checksum that’s verified during replay. If a journal block is corrupt, ext4 stops replaying at that point rather than committing partial transactions. This is a quiet feature that prevents a damaged journal from cascading into volume-level corruption.

Native encryption (fscrypt, since kernel 4.1)

ext4 added per-directory transparent encryption in Linux kernel 4.1 (June 2015) using the fscrypt subsystem. Different directories can use different encryption keys, which is unique among consumer file systems. fscrypt is what Android uses for per-user encryption on devices with file-based encryption (FBE), which is now the standard on Android 10 and later.⁷

Critically, fscrypt encrypts file content and filenames but not file system metadata (which directories exist, file sizes, timestamps). For full encryption including metadata, Linux users typically use LUKS at the block layer below ext4, not fscrypt at the file system layer.

Other features worth knowing

• Online resizing. ext4 file systems can be grown while mounted using resize2fs. Shrinking requires unmounting first.
• Online defragmentation. The e4defrag tool can defragment files while the file system is mounted (rarely needed in practice because of multiblock allocation).
• Persistent preallocation (fallocate). Reserve disk space for a file without writing zeros, used heavily by databases and torrents.
• Nanosecond timestamps. Up from ext3’s 1-second resolution.
• Up to 4 billion files per volume. Inode count is set at format time; can’t be changed without reformatting.
• Hard links and symbolic links. Standard Unix features. Hard links to files only (not directories, unlike HFS+).
• Extended attributes (xattr). Per-file metadata used for SELinux labels, ACLs, user-defined attributes.
• Lazy initialization. Inode tables can be zeroed in the background, dramatically speeding up mkfs on large volumes.

ext4 is the dominant Linux file system, but it’s not the only choice. Btrfs and XFS are increasingly common for specific use cases, and ext3 is still encountered on legacy systems. Each has trade-offs for performance, features, and recovery.⁸

Property	ext4	ext3	Btrfs	XFS
Year stable	2008	2001	2013	1994 (Linux: 2001)
Allocation	Extents	Block-pointer indirection	Extents + COW	Extents
Crash protection	Journaling	Journaling	Copy-on-write	Journaling
Snapshots	No	No	Native	No
Data checksums	No (metadata only)	No	Yes (per-block)	Optional (per-block)
Encryption	fscrypt (per-directory)	No	No native	No native
Max file size	16 TB	2 TB	16 EB	8 EB
Max volume size	1 EB	16 TB	16 EB	8 EB
Default on	Most distros, Android	Legacy systems	Fedora 33+, openSUSE	RHEL 7+ (root)
Recovery toolchain	debugfs, extundelete-ng, PhotoRec	extundelete (mature)	btrfs restore, snapshots	xfs_repair, PhotoRec
Best for	General-purpose Linux	Legacy compatibility	Snapshots, integrity	Large files, parallel I/O

When to use each

Use ext4 for: general-purpose Linux desktops and servers; Android devices (the OS chooses for you); home NAS units running QNAP QTS; embedded Linux systems. ext4 is the safe default and the file system most Linux administrators have the most experience with. The recovery toolchain is mature even though it’s not as polished as on Btrfs.

Use ext3 only for: legacy systems where compatibility with kernels before 2.6.28 matters. There’s no good reason to choose ext3 for new file systems in 2026; ext4 reads ext3 file systems natively and provides a strict superset of features.

Use Btrfs for: workloads that benefit from snapshots and cloning (similar to APFS); installations where you want per-block data checksums for silent corruption detection; Synology NAS units (Btrfs is one of the two file system options). Btrfs’s recovery story is different: snapshots make most accidental deletion trivial, and btrfs restore handles many corruption scenarios. The downside is more complexity and a steeper learning curve.

Use XFS for: large file workloads (databases, video processing); multi-threaded I/O patterns; Red Hat Enterprise Linux’s default root file system since RHEL 7. XFS performs better than ext4 on large files and parallel I/O but lacks shrink support and has historically been more conservative about features.

ext4’s failure modes are inherited largely from ext3 and from the Unix file system tradition broadly. The journal protects against most crash-induced corruption, but bad sectors, hardware failures, and operator errors all produce distinctive symptoms.⁹

• Superblock corruption. The primary superblock at the start of the volume becomes unreadable. Symptoms: mount fails with “wrong fs type, bad option, bad superblock” errors; e2fsck refuses to start. ext4 keeps backup superblocks at predictable offsets; e2fsck -b <backup_block> uses an alternate superblock to repair the primary. The backup locations are listed in the mke2fs output when the file system is created.
• Group descriptor table corruption. The table that maps block groups to their physical locations is damaged. Like the superblock, this is replicated, and e2fsck can rebuild from the backup copies.
• Inode table corruption. Bad sectors or write failures damage the inode table for one or more block groups. Files with damaged inodes are inaccessible; e2fsck will mark them as orphaned and move them to lost+found if it can read enough metadata to reconstruct.
• Journal corruption. The journal can’t be replayed, often because of bad sectors hitting the journal area. ext4 will refuse to mount cleanly. Sometimes solvable with tune2fs -O ^has_journal to remove the journal, then mount, repair, then re-enable journaling. Risky on damaged volumes.
• Cross-linked blocks. Two inodes claim the same data blocks, often as a result of incomplete recovery from earlier corruption. e2fsck’s typical fix is to clone the data into both files, which doubles the disk usage but preserves data.
• Orphaned inodes. Inodes that aren’t referenced by any directory entry. ext4 has an orphaned-inode list to handle the common case of files that were open when a crash happened; e2fsck moves them to lost+found.
• Bad sectors hitting metadata. Physical bad sectors on the underlying disk knock out specific block groups’ metadata. The remaining block groups are typically still usable, but the affected groups need careful recovery to avoid further damage.
• Delayed allocation crash. A crash before delayed-allocation writes were flushed leaves files smaller than the application thought. The journal records what was committed, not what was buffered; data buffered in memory is lost.
• Accidental rm -rf. Files deleted by the user. The directory entry is removed, the inode is wiped (block pointers zeroed), and the data blocks are marked free in the bitmap. The data clusters survive intact for a window of time; recovery via the journal can reconstruct file content if the journal still contains the old inode entries.

Warning signs your ext4 volume is failing

Linux is verbose about file system errors through dmesg and the kernel log. Watch for these in combination:

• Kernel messages about EXT4-fs errors in dmesg. The kernel reports inode and block-group level errors as they’re detected. Check with journalctl -k | grep EXT4.
• “Read-only filesystem” errors during normal use. ext4 remounts itself read-only when it detects errors that could lead to corruption. Reboot and let e2fsck run on next mount.
• e2fsck taking unusually long on routine boots. Indicates the journal is being heavily replayed, often a sign of frequent improper shutdowns or hardware issues underneath.
• Files mysteriously truncated after a crash. Often a delayed-allocation casualty. Application-level fsync calls solve this for new code; existing applications may have the bug.
• SMART warnings on the underlying disk. ext4 corruption is often the symptom of bad sectors or SSD wear; address the disk before the file system becomes unrepairable.
• Files reporting the wrong size or empty. Inode metadata corruption. The data may still be on disk; recovery software can find it.
• Slow file access on specific files. Often bad sectors being retried by the kernel’s I/O layer. Check dmesg for I/O errors.
• “Structure needs cleaning” errors. The file system has been marked dirty and needs e2fsck. Don’t keep using a dirty file system; reboot and let it run.

ext4 is everywhere in modern computing, often invisibly. It runs the underlying storage on devices most users never associate with Linux, and the recovery story changes depending on the environment.¹⁰

Linux desktops and servers

The most obvious use case. ext4 is the default file system on Ubuntu, Debian, Linux Mint, Pop!_OS, Manjaro (with btrfs as an option), Red Hat Enterprise Linux 6 (RHEL 7+ uses XFS for the root by default), and most other major distributions. For a fresh Linux install in 2026, ext4 is what you get unless you specifically pick something else. The maturity, performance, and tool ecosystem make it the safe default.

Android phones and tablets

Every Android device made in the last decade uses ext4 for the data partition. Google’s Compatibility Definition Document specifies ext4 as the file system for the userdata partition (which holds apps, app data, photos, downloads, and most user-visible content). The system partition is often read-only and may use other formats, but the data partition is ext4 with file-based encryption (fscrypt) on Android 10 and later.

The recovery implication: Android forensics is largely ext4 forensics. Tools like Autopsy, Magnet AXIOM, and Cellebrite all parse ext4 to extract data from Android devices. The data is usually fscrypt-encrypted, so recovery requires either the device to be unlocked or specialized lab tools that can extract decryption keys from the device’s secure element.

NAS units

Most consumer and SMB NAS units run ext4 internally. QNAP QTS is built on ext4. Synology DSM offers both ext4 and Btrfs as file system options; ext4 is the default on older units and on entry-level models. WD My Cloud, NETGEAR ReadyNAS, and most other consumer NAS brands use ext4 (or its variants like Btrfs which inherits some ext4 concepts) as the file system on top of their RAID layer.

The recovery implication: NAS recovery is layered (md-RAID + LVM + ext4), and each layer can fail independently. ext4 corruption on a NAS is one of the most common scenarios recovery labs see, and the standard ext4 recovery tools (debugfs, extundelete-ng, PhotoRec) all work once the underlying layers are virtually reconstructed.

Embedded Linux and IoT

ext4 is everywhere in embedded Linux: IoT devices, set-top boxes, smart TVs, routers running OpenWrt, single-board computers like Raspberry Pi, in-vehicle infotainment systems, and countless industrial control systems. The maturity, low overhead, and small code footprint make it the standard choice. For mobile/embedded use, F2FS (Flash-Friendly File System) is gaining traction, but ext4 remains the default in 2026.

ext4 advantages and drawbacks