ext2: Explanation & Insights

Linux's first real filesystem — fast, simple, and famous for the one thing it lacks: a journal.

What It Is

ext2 — the second extended filesystem — is the filesystem that made Linux a serious operating system. Written by Rémy Card in 1993, it replaced the borrowed MINIX filesystem that the early kernel had been bootstrapped on, and it laid down the design that every later ext filesystem still follows: the inode as the core abstraction, the separation of a file's name from its metadata, block groups, and the on-disk layout that ext3 and ext4 inherited almost unchanged. If you understand ext2, you understand the skeleton of the modern Linux filesystem.

The one thing that defines ext2 today is what it doesn't have: a journal. When you write to ext2, changes go straight to the live on-disk structures with no transaction log protecting them. If the power dies mid-write, the filesystem can be left internally inconsistent, and the only way to find and fix that is to scan the entire volume with fsck — slowly. That single missing feature is the whole reason ext3 was created, and the reason you should not put ext2 on a general-purpose server in 2026.

Read this page as the first chapter of a three-part story: ext2 (no journal, this page) → ext3 (adds a journal, same layout) → ext4 (adds extents and far larger limits, the modern default). ext2 is the foundation the other two are built on — which is exactly why they're so easy to convert between.

Why It Matters

You will almost never choose ext2 today, but it's worth understanding for three reasons.

First, it's the base of the family. ext3 is ext2 plus a journal; ext4 is ext3 plus extents. The block groups, the inode tables, the 5% root reservation, the fixed inode count — all of it originates here. When you read a tune2fs -l dump of an ext4 volume, you're looking at structures ext2 defined.

Second, you'll still occasionally meet it. Its narrow modern niche is small, write-light, or write-cycle-sensitive volumes where a journal adds overhead for little benefit: small /boot partitions, some flash and SD-card setups, and read-mostly appliance images. The reasoning is that a journal causes extra writes (every change is logged before it's applied), and on a volume that's rarely written — or on flash with limited write endurance — those extra writes buy you little. That niche is shrinking, but it's why ext2 isn't entirely dead.

Third, it makes the value of journaling concrete. ext2 is the "before" picture. Once you've felt the pain of a post-crash full fsck on a large ext2 volume, the journal in ext3 stops being an abstract feature and becomes the thing that gives you your evening back.

The recommendation is simple: for anything that gets written and that you care about, use ext4. Reach for ext2 only on tiny, write-light, or endurance-limited volumes where you've thought it through — never as a default.

How ext2 Works

Inodes, Names, and Data

Every file and directory on ext2 is represented by an inode: a fixed-size record holding the file's size, owner (uid/gid), permission bits, timestamps, and pointers to the data blocks. Crucially, the inode does not store the filename. The name lives in the directory entry — a simple mapping from a name to an inode number — and that separation is what makes hard links possible: two names, two directory entries, one shared inode and one shared set of data blocks.

When you create a file, ext2 allocates an inode, records the metadata there, writes the contents to data blocks, and adds a directory entry linking the name to the inode. The volume is carved into fixed-size blocks (typically 4 KB), and a free-space bitmap tracks which are used. ext2 groups blocks and inodes into block groups so that a file's metadata and its data tend to live near each other on the platter — a locality trick that keeps seeks short on spinning disks.

The Two ext-Family Quirks Start Here

Both of the ext-family surprises that catch newcomers were born in ext2 and live on unchanged in ext3 and ext4:

The inode count is fixed at format time. mkfs.ext2 decides the total number of inodes when you format and can never raise it afterwards. Fill a volume with countless tiny files and you can run out of inodes while df still reports gigabytes free — the baffling out-of-inodes error, where touch fails on a disk that looks half-empty. Check with df -i.
5% of blocks are reserved for root. Ordinary processes hit "disk full" at 95%; root can still write into that last slice — which is what lets you log in and clean up when something fills /, rather than locking you out of your own server. It's also why df and du can disagree about how full a disk is. Both behaviours are covered in depth on the ext4 page; they apply identically here.

No Journal — and What That Costs

This is the defining difference, so it's worth being precise. Writing a single file touches several structures at once: the data blocks, the inode, the directory entry, and the free-space bitmap. A journaling filesystem records its intent in a log before applying those changes, so a crash mid-write can be cleanly replayed or rolled back in seconds. ext2 has no such log. If power dies between those updates, the on-disk structures can contradict each other — an inode claiming blocks the bitmap thinks are free, a directory entry pointing nowhere — and nothing on disk knows it happened.

The only cure is fsck (specifically e2fsck) walking the entire volume — every inode, every block, every directory — hunting for contradictions and patching them. On a small disk that's quick. On a large one it's minutes to hours, during which the server sits there refusing to boot. And it happens after every unclean shutdown, because ext2 can't tell a clean stop from a crash without scanning. That, in one sentence, is why ext3 exists.

Warning

An ext2 volume that suffers a power cut may need a full fsck before it will mount, and on a large disk that check can take a long time — long enough to turn a quick reboot into a lengthy outage. If a box must survive sudden power loss and reboot fast, that volume should be ext4, not ext2. The journal is the difference between "back in seconds" and "back after the surface scan finishes."

One nuance worth keeping straight, because it carries through the whole family: even a journal protects the filesystem structure, not your file contents. ext2's gap is purely that it lacks even the structural protection — so it pays the slow-fsck price that ext3 eliminated. Neither one is a substitute for backups.

How I Inspect It

ext2 shares the ext-family toolset, so this will look familiar if you've seen the ext4 page.

tune2fs -l /dev/sdb1

Filesystem UUID:          a1b2c3d4-e5f6-7890-abcd-ef1234567890
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super
Filesystem state:         clean
Inode count:              655360
Block count:              2621440
Reserved block count:     131072
Block size:               4096

The tell that this is ext2 and not its descendants: no has_journal in the feature line (that flag is what makes a volume ext3) and no extent (which would make it ext4). ext2 has neither.

The rest is standard: df -hT shows space and the ext2 type, df -i shows inode usage, and e2fsck — on an unmounted volume only — checks and repairs.

Cheat Sheet

# --- Identify ---
tune2fs -l /dev/sdb1 | grep features   # ext2 = NO has_journal, NO extent
df -hT                                  # type column shows "ext2"
df -i                                   # inode usage (count is fixed at format time)

# --- Create (only for tiny / write-light volumes) ---
mkfs.ext2 /dev/sdb1                      # format as ext2
mkfs.ext4 /dev/sdb1                      # what you should usually run instead

# --- Inspect ---
tune2fs -l /dev/sdb1                     # superblock: inode count, block size, reserved blocks
dumpe2fs /dev/sdb1 | less                # full forensic dump

# --- Tune ---
tune2fs -m 1 /dev/sdb1                    # lower the 5% root reservation to 1%
tune2fs -L boot /dev/sdb1                 # set a volume label

# --- Check and repair (UNMOUNT FIRST) ---
e2fsck -f /dev/sdb1                       # forced full check — the slow scan ext2 always needs
fsck -f /dev/sdb1                         # generic front-end, dispatches to e2fsck

# --- Upgrade to ext3 (add a journal) ---
tune2fs -j /dev/sdb1                      # then change fstab type ext2 -> ext3

# --- Upgrade straight to ext4 ---
umount /dev/sdb1
tune2fs -O has_journal,extents,uninit_bg,dir_index /dev/sdb1
fsck -f /dev/sdb1                         # then change fstab type ext2 -> ext4

Pro Tip

Turning an ext2 volume into a journaled one doesn't require reformatting or moving any data — tune2fs -j adds a journal and you have ext3; add extents as well and you have ext4. The filesystem stays in place the whole time. There's rarely a reason to leave a writable volume on ext2 once you know the upgrade is this cheap.

Gotchas

Every unclean shutdown means a full fsck. With no journal, ext2 must scan the whole volume to find damage, and on a large disk that's a long outage. This is the headline reason to use ext4 on anything that matters.
Inode exhaustion looks like a full disk. The inode count is fixed at format time and can't be grown. df shows free space while touch fails — run df -i. See out of inodes.
"100% full" with space free, and root can still write. The 5% reservation, same as the rest of the family. Drop it on data volumes with tune2fs -m 1 (never to zero); it's also why df and du disagree.
fsck on a mounted ext2 volume can corrupt it. Always unmount first.
Don't reach for ext2 to "save journal overhead" on a normal server. The overhead is small; the post-crash fsck cost is large. The trade only makes sense on genuinely tiny, write-light, or flash-endurance-limited volumes.

History and Philosophy

ext2's story is the story of Linux growing up. When Linus Torvalds started the kernel in 1991, he borrowed Andrew Tanenbaum's MINIX filesystem to have somewhere to put files — but MINIX was a teaching system, and it showed: filenames capped at 14 characters, volumes capped at 64 MB. Linux outgrew it almost at once. Rémy Card's first "extended filesystem" (ext, 1992) lifted those limits but had its own rough edges, and a year later he replaced it with ext2 — a clean, robust design built on the classic Unix filesystem model of Ken Thompson and Dennis Ritchie: the inode, the hierarchical directory tree, and the principle that name and metadata are separate things.

ext2 was good. Good enough that it carried Linux off the hobbyist desktop and into the server room, where it ran for most of a decade. Its design was forward-looking in ways that paid off later: it reserved feature-flag space in the superblock so future versions could add capabilities without breaking compatibility — which is precisely the mechanism that let ext3 later add a journal, and ext4 add extents, both on top of an existing ext2 volume with nothing but a flag change. Card built a foundation that could be extended without being torn down, and three decades later the filesystem under most Linux servers is still standing on it.

The lack of a journal wasn't an oversight — in 1993, journaling filesystems were exotic and disks were small enough that a full fsck was tolerable. By 2001, disks had grown and the calculus had flipped, which is when ext3 arrived to close the gap. ext2 didn't fail; it simply finished its era and handed the baton to a successor it had been designed, all along, to become.