ext3: Explanation & Insights

The release that gave Linux a journal — and ended the era of watching fsck crawl after every crash.

What It Is

ext3 — the third extended filesystem — is the version of Linux's native filesystem that introduced journaling to the mainstream. Shipped in 2001, it took the proven, widely-deployed ext2 and added one transformative feature: a journal that lets a server recover from a crash in seconds instead of grinding through a full-disk consistency check for an hour. For most of the 2000s, ext3 was the Linux server filesystem. Today it's been superseded by ext4 — but it's still worth understanding, both because you'll meet it on older servers and because it's the cleanest possible illustration of what a journal does and doesn't do.

The defining fact about ext3 is its restraint. It is ext2 with a journal bolted on top of the exact same on-disk layout — same blocks, same inode structure, same directory format, same block-pointer scheme for tracking where a file's data lives. Stephen Tweedie, who wrote it, deliberately chose not to redesign anything. That conservatism had a remarkable payoff: an ext2 volume could be converted to ext3 (and back) just by adding or removing the journal, with the data untouched. The trade-off was that ext3 inherited ext2's older, less efficient data structures — which is precisely the gap ext4 later closed with extents.

If you're new to all this, read this page as the middle chapter of a three-part story: ext2 (no journal) → ext3 (adds the journal, keeps the layout) → ext4 (adds extents and much larger limits, the modern default). ext3 is the hinge — the moment Linux storage stopped fearing the power cut.

Why It Matters

ext3 matters today for two reasons, and neither is "you should format a new volume with it" — you shouldn't.

First, you'll inherit it. Servers installed in the 2000s and early 2010s, long-lived appliances, embedded systems, and the occasional /boot partition still run ext3. When you take one over, you need to recognise it, inspect it, and know that upgrading it in place to ext4 is a two-command job rather than a backup-and-restore ordeal — because, again, they're the same family with the same layout.

Second, ext3 teaches the one filesystem concept everyone gets muddy. Because it's ext2 plus only a journal, ext3 isolates exactly what journaling buys you and what it doesn't, with no extents or delayed allocation muddying the picture. If you understand ext3's journal, you understand ext4's journal — they're the same mechanism with the same three data modes. So this page spends its depth there.

My actual recommendation is blunt: don't create new ext3 filesystems. Use ext4 — it's strictly better, fully backward-compatible, and reads everything ext3 can. ext3's value now is historical and diagnostic, not prescriptive.

Journaling — What ext3 Actually Added

This is the heart of the page, because the journal is ext3's entire reason for existing.

The Problem ext2 Had

Writing one file is never a single operation underneath. The filesystem has to update several structures at once: the data blocks, the inode (size and timestamps), the directory entry, and the free-space bitmap. If the power dies between those updates, some land and some don't, and the on-disk structure is now internally contradictory — an inode claiming blocks the bitmap thinks are free, a directory pointing at an inode that was never written. On journal-less ext2, the only way to find and fix this was fsck walking every inode, block, and directory on the whole volume. On a large disk that meant an hour of downtime after every unclean shutdown, every time.

What the Journal Does

ext3 borrows an idea straight from database transaction logs. Before touching the live filesystem structures, it writes a description of the intended change into a small dedicated area — the journal — and marks it committed. Then it applies the change to the real structures. If the machine crashes mid-write, recovery doesn't scan the disk; it just replays the journal: complete any fully-committed transaction, discard any that wasn't finished. Recovery takes seconds, regardless of how big the volume is. That single change is why an ext3 server boots cleanly after a crash while an ext2 one made you wait.

What the Journal Does Not Do — The Muddy Part

Here is the thing nearly every tutorial leaves fuzzy, and ext3 is the perfect place to nail it down: the journal keeps the filesystem's structure consistent — it does not guarantee your file contents survive a crash. Those are two different promises.

A consistent filesystem after a crash means fsck is near-instant and the metadata makes sense — no orphaned inodes, no double-allocated blocks. It does not mean the data you wrote in the last few seconds made it to the platter. By default it may simply be gone, cleanly, with no error. The journal protects the bookkeeping, not the book. This is exactly why a journaling filesystem is still not a substitute for backups or for an application calling fsync when it genuinely needs durability — and it carries over identically into ext4.

The Three Data Modes

ext3 introduced the data= mount option that ext4 inherited unchanged. It controls how much goes through the journal — the lever between safety and speed:

data=ordered — the default, and the right choice almost always. Only metadata is journaled, but ext3 guarantees the file's data blocks are flushed to disk before the metadata transaction referencing them commits. So after a crash you can lose the last few seconds of writes, but you'll never read an inode pointing at stale, deleted bytes that belonged to someone else.
data=writeback — metadata is journaled, but with no ordering between data and metadata. After a crash an inode can legitimately point at blocks that were never written, so a freshly-created file can come back full of whatever junk those blocks held before — possibly fragments of a deleted file. Technically "consistent," genuinely unsafe, and a quiet information-leak risk. Don't.
data=journal — full data journaling. Both metadata and data go through the journal, so a committed write is truly durable — but every byte is written twice, roughly halving write throughput. For the rare workload that cannot tolerate losing any acknowledged write.

Note

A journal makes fsck near-instant after a crash because recovery is a quick replay rather than a full surface scan — but "fast fsck" and "my data is safe" are different guarantees. The journal delivers the first. The second comes from data mode, application fsync discipline, and backups. Conflating them is the single most common misunderstanding about journaling filesystems.

How I Inspect It

The ext family shares its tooling, so inspecting ext3 looks identical to inspecting ext4 — the same df, tune2fs, and e2fsck.

The fastest way to tell ext3 from ext4 is the feature flags in the superblock:

tune2fs -l /dev/sdb1

Filesystem UUID:          a1b2c3d4-e5f6-7890-abcd-ef1234567890
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype
                          sparse_super large_file
Filesystem state:         clean
Block size:               4096
Reserved block count:     1525000

The tell is has_journal present but extent absent. That combination is ext3: it has the journal (that's what makes it ext3 rather than ext2) but lacks extents (which is what would make it ext4). An ext2 superblock shows neither; an ext4 one shows both.

Everything else carries over from the family: df -hT for space and type, df -i for inode usage (ext3's inode count is also fixed at format time — the same out-of-inodes trap), and fsck — on an unmounted volume only — to check and repair.

Cheat Sheet

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

# --- Create (you probably shouldn't — use ext4) ---
mkfs.ext3 /dev/sdb1                        # format as ext3
mkfs.ext4 /dev/sdb1                        # what you should actually run instead

# --- Tune ---
tune2fs -m 1 /dev/sdb1                      # lower the 5% root reservation to 1%
tune2fs -L data /dev/sdb1                   # set a volume label
tune2fs -O ^has_journal /dev/sdb1           # strip the journal -> back to ext2 (rarely wanted)

# --- Check and repair (UNMOUNT FIRST) ---
fsck -f /dev/sdb1                           # forced full consistency check
e2fsck -p /dev/sdb1                         # "preen" — fix safe issues automatically

# --- Upgrade in place to ext4 ---
umount /dev/sdb1
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
fsck -f /dev/sdb1                           # then change fstab type ext3 -> ext4

Pro Tip

If you find an ext3 volume, the right move is almost never "keep it as ext3." Either leave it alone if it's a stable legacy system you don't want to touch, or upgrade it in place to ext4 — there is essentially no reason to stay on ext3 when ext4 reads the same data, adds extents, and costs you nothing to switch.

The 5% Reservation and Fixed Inodes

ext3 carries the two ext-family quirks worth knowing about, both unchanged in ext4:

The 5% root reservation. mkfs.ext3 sets aside 5% of blocks for root. Ordinary processes hit "disk full" at 95%, but root can still write into that reserve — which is what lets you log in and clean up when a runaway log fills /, instead of being locked out of your own server. It's also why df (which knows about the reservation) and du (which just sums file bytes) report different numbers. On a big data volume, drop it with tune2fs -m 1 — but never to zero.
Inode count fixed at format time. Like all ext filesystems, ext3 decides the total inode count when you format and can never raise it. A flood of tiny files can exhaust the inodes while df still shows free space — the out-of-inodes surprise. Check with df -i.

Both behaviours are explained in full on the ext4 page; they're identical on ext3 because they predate the split.

Upgrading to ext4

Because ext3 is ext2-plus-a-journal, and ext4 is ext3-plus-extents, you can migrate an ext3 volume to ext4 in place — no reformat, no data movement:

umount /dev/sdb1
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
fsck -f /dev/sdb1

Then change the type in /etc/fstab from ext3 to ext4 and remount. Existing files keep their old block-pointer layout; only new files get extents, so it's not as clean as a fresh ext4 format — but it's instant and gets you the modern feature set without touching your data. The same chain works one step further back from ext2, adding has_journal first.

Gotchas

The journal is not data protection or a backup. It keeps the structure consistent so fsck is fast; it does not save the last seconds of writes, and it does nothing against rm -rf, a bad deploy, or a failing disk. You still need backups.
data=writeback for speed is a false economy. The gain is marginal; the cost is crashed files coming back full of stale, deleted bytes. Stay on data=ordered.
Don't create new ext3 volumes. ext4 is strictly better and fully compatible. ext3's only remaining roles are legacy systems and the occasional ancient /boot.
fsck on a mounted ext3 volume can corrupt it. Always unmount first.
Inode exhaustion looks like a full disk. Same fixed-inode trap as the rest of the family — check df -i. See out of inodes.

History and Philosophy

ext3 was written by Stephen Tweedie and merged into the Linux kernel in 2001. By then ext2 had carried Linux for the better part of a decade, but disks had grown and so had the agony of its weakness: every unclean shutdown meant a full fsck, and a full fsck on a multi-gigabyte volume could hold a server hostage for an hour. Journaling filesystems already existed elsewhere — IBM's JFS, SGI's XFS, Hans Reiser's ReiserFS — but they all asked you to abandon ext2 and migrate.

Tweedie's insight was that you didn't have to. Rather than design a new filesystem, he added a journal on top of ext2's existing layout, so an ext2 volume could become ext3 simply by allocating a journal and setting a flag — and revert just as easily. That backward-compatibility-by-construction is the most elegant thing about ext3, and it's exactly what made the upgrade path painless enough that the whole Linux world moved over within a few years.

The same conservative DNA shaped what came next. When the limitations of ext2's data structures — particularly the block-pointer scheme that fragmented large files — finally needed solving, the maintainers (led by Theodore Ts'o) chose to fork the development branch into ext4 rather than risk destabilising the ext3 that production servers everywhere depended on. ext3 stayed boring and trustworthy while its successor took the risks. That's the ext philosophy in one move: protect the version people are betting their data on, and let the new ideas prove themselves under a different name first.