ext4, ext3 and ext2, explained.

What ext2, ext3 and ext4 are

ext2, ext3 and ext4 are the second, third and fourth extended file systems – the formats Linux has used for its own disks for more than thirty years. A file system decides how files, folders, names, permissions and dates are laid out on a disk, so that any computer that knows the format can find them again.

ext4 is the one you meet today. Debian, Ubuntu and Raspberry Pi OS format their disks with it, it is the usual choice for a Linux server’s data disk, and Google moved Android phones to it in 2010. A USB drive or SD card that has been prepared on Linux is almost always ext4.

The three are one family rather than three different formats. Each generation kept the on-disk layout of the one before and added to it, which is why current Linux kernels read and write all three with a single ext4 driver.

A short history

1. 1992

   ext, the extended file system

   Rémy Card writes it for Linux 0.96c to replace the Minix file system Linux started with, whose limits on disk size and file names were already too small.

2. 1993

   ext2

   A redesign in January 1993, for Linux 0.99, borrowing ideas from BSD’s Fast File System: the disk split into block groups, separate access, change and modification times. It stays Linux’s standard for the rest of the decade.

3. 2001

   ext3 adds a journal

   Stephen Tweedie’s ext3 enters the mainline kernel with Linux 2.4.15 in November 2001. The layout is ext2’s, so an ext2 disk becomes ext3 by adding a journal, but a crash no longer means a long check of the whole disk.

4. 2006

   Work on ext4 begins

   Theodore Ts’o announces the plan on 28 June 2006, building on extensions developed for the Lustre cluster file system. A development version, ext4dev, appears in Linux 2.6.19.

5. 2008

   ext4 is declared stable

   Linux 2.6.28, released on 25 December 2008, brings extents, 64-bit block numbers, delayed allocation and nanosecond timestamps.

6. 2013–2021

   Checksums, encryption, case-folding

   Later kernels add inline data (3.8), metadata checksums (3.18), encryption (4.1), case-insensitive folders (5.2), verity (5.4), fast commits (5.10) and the orphan file (5.15).

How ext4 lays out a disk

Blocks. ext4 hands out space in blocks, usually 4 KiB each; the size is chosen when the disk is formatted and can be anything from 1 KiB to 64 KiB. Even a one-byte file takes a whole block, unless the disk uses inline data.

Block groups. The disk is split into groups of blocks – with 4 KiB blocks, 32,768 blocks or 128 MiB each. Every group has two bitmaps, one saying which of its blocks are in use and one for its inodes, plus its part of the inode table. Keeping a file’s data close to its inode keeps the drive’s head from travelling. ext4’s flex_bg gathers the bitmaps and inode tables of several groups together, so large files can run across group boundaries in one piece.

The superblock. The first thing on the disk after 1 KiB of padding: how big the file system is, its block size, which features it uses and whether it was unmounted cleanly. Copies sit in several block groups, so a damaged superblock can be restored from a backup.

Inodes. Every file and folder has one inode, 256 bytes by default. It holds the owner, the permissions, the timestamps, the size and where the data lies – everything except the name. The number of inodes is fixed when the disk is formatted, so a disk full of tiny files can run out of inodes while it still has free space.

Directories. A folder is a special file that maps names to inode numbers. Names can be up to 255 bytes long. Small folders are a plain list; large ones get an index, a hashed tree (dir_index, “htree”), so that finding one name among a hundred thousand takes a few block reads, not a scan.

Extents instead of block maps. ext2 and ext3 record every block of a file one by one: twelve direct pointers in the inode, then blocks full of pointers, pointers to those, and pointers to those again. ext4 records runs instead. An extent says “this many blocks, starting here”, up to 32,768 blocks (128 MiB with 4 KiB blocks) in one entry. Four extents fit in the inode itself; a longer, more fragmented file gets an extent tree up to five levels deep. A large, contiguous file is described in a handful of entries instead of thousands.

Small files can live inside their inode. With the inline_data feature, up to 60 bytes of a file are stored in the inode itself, and a little more in its extended-attribute space, without using a block at all.

The journal, and what it protects

Changing a file system is never one write. Creating a file touches a bitmap, an inode, a directory and a counter in the group descriptor. If the power goes between two of those writes, the disk is left half-changed – and ext2 could only find out by checking the whole disk with e2fsck, which on a large disk took a long time.

ext3 and ext4 keep a journal: a reserved area of the disk, usually inode 8, where changes are written before they happen. A change travels in three steps. First the new blocks go into the journal. Then a commit record marks the transaction complete. Only after that are the blocks written to their real places – the checkpoint. If the power goes at any point, the next mount replays the journal: transactions that reached their commit are applied again, and anything without a commit is thrown away. The file system comes back consistent in seconds.

The journal is not a backup. It keeps the file system’s structure intact and guarantees whatever was committed; it can’t bring back a change that was still on its way, and it doesn’t protect against a failing disk. ext4 can also write fast commits (Linux 5.10): small records of just the changed metadata, between full commits, to make frequent fsync calls cheaper.

A Raspberry Pi card pulled out while the Pi was running is exactly this case. Its journal still holds committed transactions that never reached their final places, and the superblock says “needs recovery”. Linux replays it at the next mount; software that reads the card elsewhere has to replay it too, or it shows the files as they were before those transactions.

ext2 vs ext3 vs ext4

In practice: use ext4 for anything new. ext3 has no reason to exist on a fresh disk, and ext2 survives where a journal is unwanted – a small boot partition, or flash media that should be written as little as possible. An ext3 disk can be converted to ext4 in place, but files that were already on it keep their block maps until they are rewritten.

Features you meet on real disks

Rather than version numbers, an ext disk carries feature flags in its superblock, and each flag belongs to one of three kinds. A compatible feature can be ignored by software that doesn’t know it. A read-only compatible feature means such software may read the disk but must not write to it. An incompatible feature means it must not touch the disk at all. That rule is why an older tool refuses a newer disk instead of damaging it.

Where they turn up: current mke2fs switches on metadata_csum and 64bit by default, and e2fsprogs 1.47 added orphan_file and metadata_csum_seed, which some distributions switch off again so that older boot loaders can still read the disk. The Raspberry Pi OS image is made without 64bit. A Steam Deck formats its microSD cards with casefold, and Android uses encrypt.

To see which features a disk uses, read its superblock on Linux with sudo dumpe2fs -h /dev/sdX1 and look at the “Filesystem features” line.

Limits

The 64-bit figures are what the format can address; the extent format and the tools cap real file systems at around 1 EiB. Other limits that matter more often:

• A file or folder name: 255 bytes – fewer characters in scripts that need more than one byte per character.
• Hard links to one file: 65,000, which means at most 64,998 subfolders in one folder.
• Timestamps: nanosecond precision, valid until May 2446 with 256-byte inodes; 128-byte inodes stop in January 2038.
• Inodes: fixed at format time, one per file or folder, at most about four billion.

Checking and repairing an ext4 disk

Checking and repairing ext file systems is the job of e2fsck, part of e2fsprogs, on Linux. It works on a disk that is not mounted; running it on a mounted file system can damage it.

sudo dumpe2fs -h /dev/sdX1      # superblock: features, state, last check
sudo e2fsck -fn /dev/sdX1        # full check, read-only: reports, changes nothing
sudo e2fsck -f /dev/sdX1         # full check with repairs, asks before each
sudo tune2fs -l /dev/sdX1        # the same superblock summary
sudo mkfs.ext4 -L DATA /dev/sdX1 # a new ext4 file system (erases the partition)

Replace /dev/sdX1 with the partition in question – lsblk lists them. After an unclean shutdown there is usually nothing to do: the next mount replays the journal. A full check is worth running when Linux has recorded an error in the superblock, when checksums fail, or after the disk has been in a device that crashed repeatedly.

ext4 and other file systems

For a drive that moves between Linux, Mac and Windows with nothing installed, exFAT is the common ground – at the cost of Linux permissions, owners, symbolic links and any protection when the cable comes out mid-write. ext4 keeps all of those, and needs extra software on the Mac and on Windows.

Reading ext4 on a Mac or on Windows

macOS reads none of the ext file systems. Plug in a Linux disk and it says “The disk you attached was not readable by this computer”, offering Initialize, Ignore and Eject. Initialize erases the disk; choose Ignore or Eject.

Since macOS 15.4, Apple’s FSKit lets a file system run as an ordinary app extension outside the kernel, the way Apple’s own newer file systems do. That is the route that needs no kernel extension and no lowered security settings. The other routes are a kernel extension, a user-space layer such as FUSE, or a Linux virtual machine that is given the disk.

On Windows 11, WSL 2 can mount a Linux disk: wsl --mount \\.\PHYSICALDRIVE2 --partition 1 --type ext4 in an administrator’s terminal, after which the files appear in Explorer under \\wsl$\ and the distribution’s /mnt/wsl folder. It works only with disks attached directly to the PC, not with USB drives or SD card readers; those have to be passed to WSL through USB/IP first.

Extent is our own FSKit file system for ext2, ext3 and ext4 on macOS 27. A Linux disk shows up in the Finder like any other; reading is free, and writing to ext4 goes through the disk’s journal, as on Linux. A card pulled from a Pi without shutdown is read with its journal replayed in memory.

Frequently asked questions