ext4

ext4, the fourth extended filesystem, is a journaling filesystem for Linux that organizes data on a disk partition into inodes, directories and contiguous block ranges called extents. It became stable in Linux kernel 2.6.28 in December 2008 as the successor to ext3 and remains the default filesystem of Debian, Ubuntu and many other distributions.

In the Linux filesystem landscape, ext4 is the conservative, well-understood choice: it lacks the snapshots and data checksums of Btrfs and the extreme scalability of XFS, but it offers mature recovery tools, predictable performance and backward compatibility with ext2 and ext3 volumes.

How the fourth extended filesystem stores data

An ext4 volume is divided into block groups, each holding a slice of the inode table, allocation bitmaps and data blocks. The superblock at the start of the volume records global parameters such as block size, inode count and enabled features, and backup copies are kept in selected block groups for recovery.

Every file and directory is described by an inode, a 256-byte record by default that stores ownership, permissions, timestamps and the location of the data. Instead of ext3’s lists of individual block pointers, ext4 maps data with extents: each extent describes up to 32,768 contiguous blocks, which equals 128 MiB with 4 KiB blocks. Four extents fit directly in the inode, and larger files use an extent tree.

Allocation is tuned to keep files contiguous. Delayed allocation postpones choosing disk blocks until data is flushed from the page cache, the multiblock allocator reserves many blocks in one operation, and flex_bg groups metadata of neighboring block groups together to reduce seeks.

Journaling modes and crash consistency

The journal is a circular log in which ext4 records changes before applying them to their final location. After a power loss, the kernel replays committed transactions at mount time, so the filesystem returns to a consistent state in seconds instead of requiring a full scan. By default the journal commits every 5 seconds, set with the commit= mount option.

The journaling mode decides what is protected and at what cost. The table compares the three modes selected with the data= mount option.

Journaling protects filesystem structure, not application data. A program that needs durability must still call fsync, because data held in the page cache can be lost if power fails before it is written. Since kernel 3.6, ext4 can also protect metadata with CRC32C checksums through the metadata_csum feature, now enabled by default when a filesystem is created.

Limits and key parameters

Most ext4 limits depend on the block size, which is 4 KiB on almost all systems because it must not exceed the memory page size. The values below apply to that common configuration with the 64bit feature enabled.

Two parameters are chosen once, at creation time. The inode count follows from the bytes-per-inode ratio (16 KiB by default), so a volume filled with millions of tiny files can run out of inodes while free space remains. The block size cannot be changed later either; a different value requires reformatting.

How ext4 compares with XFS and Btrfs

The three general-purpose Linux filesystems target different priorities: ext4 favors simplicity and robustness, XFS scales to very large volumes and parallel I/O, and Btrfs adds integrity and snapshot features through copy-on-write.

ext4 can be grown while mounted with resize2fs, but shrinking requires unmounting. For a boot disk, a general server or a virtual machine image, it remains a safe default; for petabyte-scale storage or systems that rely on rollback snapshots, XFS or Btrfs is usually the better fit.

Administration and common mistakes

ext4 is managed with the e2fsprogs toolset. Its utilities create, inspect, tune and repair volumes, and most administrative errors involve using them at the wrong moment.

• Create a filesystem with mkfs.ext4 /dev/sdb1, adding -i or -N when many small files are expected.
• Never run e2fsck on a mounted filesystem; check it unmounted or from rescue media to avoid corruption.
• Inspect settings with tune2fs -l or dumpe2fs -h, and lower the reserved space on large data volumes with tune2fs -m 1.
• Watch inode usage with df -i, because inode exhaustion produces no space errors even when df -h shows free capacity.
• Defragment rarely; extents keep fragmentation low, and e4defrag is needed only for heavily fragmented files.

A non-technical view

Think of a disk as a huge warehouse and ext4 as its filing system and logbook. The filing system remembers which shelves hold each file. Large files are stored in long, continuous runs of shelves, so they can be fetched quickly.

The logbook notes every planned change before it is made. If the power fails halfway, the warehouse staff read the logbook and finish or cancel the change. The structure stays orderly even after a sudden crash, which is why ext4 is trusted as a dependable default.

A concrete example

A hosting provider prepares a 2 TB ext4 volume for a mail server that will store tens of millions of small messages. With the default ratio of one inode per 16 KiB, the volume would get about 122 million inodes, which the team considers too tight for growth. They format it with mkfs.ext4 -i 8192, doubling the count to roughly 244 million inodes, and lower the root reserve from 5% to 1% with tune2fs -m 1, freeing about 80 GB.

Months later, a power failure hits the data center. On restart, ext4 replays its journal in a few seconds and the mail service is back without a full filesystem check. No messages are lost because the mail server software calls fsync before confirming delivery, which complements the protection that ordered journaling gives the metadata.