Linux online course

ext3 File System in Linux

Learn how the Linux ext3 file system works, including journaling, ext2 and ext4 differences, limits, creation, mounting, inspection, repair, and migration.

ext3, also called the third extended file system or ext3fs, is a Linux file system format derived from ext2. Its defining improvement over ext2 is journaling: recording file system transactions on disk so the system can recover metadata more quickly after a crash or power loss.

ext3 was a common default file system on Linux distributions for many years. ext4 is generally its modern successor, but ext3 remains relevant when supporting older kernels, legacy boot environments, existing installations, or conservative compatibility requirements.

What ext3 is and where it fits

A file system defines how files, directories, metadata, and free space are organized on a block device such as a partition. A kernel file system driver implements that format, while user-space tools such as mkfs.ext3 and e2fsck create or maintain it. These are related but distinct concepts: a disk format is not the same thing as the driver or administration commands used with it.

ext3 retains the basic ext2 design and adds a journal. This relationship provides useful compatibility: in some circumstances an ext3 volume can be mounted as ext2 with its journal disabled or unused. That should be treated as a deliberate compatibility choice, not as proof that journaling is unnecessary.

How journaling works

A journal is a region of on-disk transaction information. File operations often require several metadata updates: for example, creating a file may require changing an inode, adding a directory entry, and updating free-space records. If power fails between those updates, the structures can disagree.

With journaling, ext3 records a transaction before or while applying the related changes. After an unclean shutdown—a crash, reset, or power failure rather than a normal unmount—the kernel can perform journal replay during mounting or recovery. Replay applies completed transactions or finishes the recorded metadata work, restoring file system consistency without examining every block in the usual way.

Journal replay is rapid recovery, not a guarantee that every recently written application byte survived. An application may not have synchronized its data, and the journal may contain only metadata. Journaling also does not eliminate every possible check: hardware faults, severe corruption, or incomplete recovery can still require an offline file system check.

ext3 journaling modes

The data= mount option selects the usual ext3 data-journaling policy. Metadata means information describing files and directories, such as ownership, permissions, timestamps, sizes, and block mappings.

These modes represent trade-offs among durability, consistency, and performance. A database-like workload should not automatically use the fastest option; application synchronization, storage write caches, and recovery requirements must also be considered.

On-disk structure

Several structures work together in an ext3 volume:

• Superblock: core metadata describing the file system size, layout, state, block size, and features. Backup copies may exist in other locations.
• Block groups: local allocation regions that organize related metadata and data blocks.
• Inodes: structures holding file metadata and references to the blocks containing file data. An inode does not normally store the file name.
• Directory entries: mappings from names to inode numbers. This is why a file name and the file's inode are separate concepts.
• Data blocks: storage for file contents and, where applicable, directory contents.
• Journal: an on-disk transaction area used for recovery. It improves crash consistency but is not a backup.

Free space reported to an ordinary user can differ from the total free space reported by administrative tools. ext3 may reserve blocks for privileged use, and space is also consumed by inodes, directories, and the journal. Deleted files can continue consuming space while a process still has them open.

Capabilities and common limits

Use TiB for tebibytes, based on powers of 2, and TB for decimal terabytes. The commonly cited ext3 figures are approximate operational limits rather than a promise that every combination of hardware, kernel, block size, and tools supports them identically.

Creating an ext3 file system

Formatting creates a new file system and normally erases the existing file system and its data. Partition the device first, confirm the exact partition, and unmount it before formatting. The following example assumes /dev/sdb1 is an unused, unmounted partition; do not copy it blindly.

lsblk -f
findmnt
sudo umount /dev/sdb1
sudo mkfs.ext3 -L archive /dev/sdb1
sudo blkid /dev/sdb1

You can also use the generic command with an explicit type:

sudo mkfs -t ext3 -L archive /dev/sdb1

Check the output from blkid for the file system type, label, and UUID. A UUID is a persistent identifier for the file system and is usually safer for configuration than a device name such as /dev/sdb1.

Mounting an ext3 volume

A mount point is a directory where the contents of a file system become available. This temporary mount does not by itself configure mounting at boot.

sudo mkdir -p /mnt/archive
sudo mount -t ext3 /dev/sdb1 /mnt/archive
findmnt /mnt/archive

Linux can often detect the type automatically, so the explicit -t ext3 is mainly useful for clarity and instruction. Unmount the volume before removing it or performing maintenance:

sudo umount /mnt/archive

Persistent mounting with /etc/fstab

/etc/fstab defines file systems that Linux can mount automatically. Prefer a UUID or a human-readable LABEL over a volatile device name.

sudo mkdir -p /srv/archive
sudoedit /etc/fstab

UUID=example-uuid /srv/archive ext3 defaults,relatime 0 2

Replace example-uuid with the actual value from blkid. Then test the entry before rebooting:

sudo mount -a
findmnt /srv/archive

If the volume is optional, nofail can allow the system to continue when it is unavailable, but use it only when that behavior is safe. Mount options should match the workload and be tested before production use.

• defaults selects a conventional group of default options.
• relatime reduces access-time writes while retaining useful access-time behavior.
• noatime suppresses access-time updates and can reduce writes, but applications that depend on access times may behave differently.
• data=ordered, data=journal, and data=writeback select the journaling modes described above.

Inspecting an ext3 volume

Start with read-only identification commands. These help distinguish a partition, its file system, its mount point, and its configuration.

lsblk -f
sudo blkid
findmnt -t ext3
df -Th

lsblk shows block-device relationships and file system fields, blkid reports signatures such as type, UUID, and label, findmnt shows active mounts and options, and df -Th reports mounted file system types and space usage.

For ext-family metadata, journal information, mount counts, check intervals, and feature flags, use:

sudo tune2fs -l /dev/sdb1
sudo dumpe2fs -h /dev/sdb1

The -l and -h forms display information without changing settings. Read the output before using commands that alter labels, check intervals, reserved blocks, or other parameters.

Changing a label

sudo e2label /dev/sdb1 archive
sudo blkid /dev/sdb1

An equivalent ext-family method is:

sudo tune2fs -L archive /dev/sdb1
lsblk -f

Checking and repairing ext3

Use e2fsck or fsck.ext3 after corruption reports, repeated improper shutdown problems, or before planned repair. A repair check must normally run against an unmounted file system, usually from a maintenance or rescue environment.

sudo umount /dev/sdb1
sudo e2fsck -f /dev/sdb1

The command above performs a forced check and normally asks before making repairs. A read-only check can be useful when you need assessment without changes:

sudo e2fsck -fn /dev/sdb1

Automatic-answer options such as -y can accept repairs without prompting. They may discard damaged metadata or data, so use them only with strong justification, current backups or an image when possible, and an understanding of the consequences. Do not run a repairing check against a normally mounted read-write volume.

Scheduled checks

ext3 can request periodic checks based on mount counts or elapsed time. Inspect these settings with:

sudo tune2fs -l /dev/sdb1

Look for the maximum mount count and check interval. Administrators can alter those settings with tune2fs, but scheduling should account for volume size, maintenance windows, and the risk of delaying detection.

Recovery priorities

1. Stop unnecessary writes and preserve evidence of the failure.
2. Review kernel and system logs for I/O errors.
3. Obtain a backup or block-level image when possible, especially if hardware failure is suspected.
4. Use a maintenance environment and verify that the target is unmounted.
5. Run an appropriate check, then investigate recurring hardware or shutdown problems.

Troubleshooting common problems

A check is requested after a crash

An unclean shutdown may require journal replay, and a detected metadata inconsistency or underlying storage error may require a full offline check. Determine whether the volume is mounted, review logs for I/O errors, and use a maintenance environment if repair is needed. Recurring errors require hardware investigation rather than repeated blind repairs.

An /etc/fstab entry fails

• Compare the configured UUID or LABEL with blkid.
• Verify that the mount-point directory exists.
• Check the file system type and option spelling.
• Run sudo mount -a and inspect the resulting error and system logs.
• Use nofail only when booting without the volume is safe.

The device is already mounted or busy

Use findmnt and lsblk to locate an existing mount. A process may have an open file or current directory under the mount point. After identifying dependencies, stop the relevant services and unmount cleanly. Tools such as lsof or fuser can help identify users of the mount.

Users cannot use all reported free space

Compare df with file-level usage. Reserved blocks may be available to privileged processes but not ordinary users. Metadata and journal structures also consume space. Check for deleted-but-open files before changing reserved-block policies.

Recent contents are stale after recovery

Recovery can restore file system metadata without preserving every application write. The application may not have called fsync, the selected mode may not journal full data, or a storage write cache or hardware fault may have lost writes. Review application durability behavior and whether the journaling mode matches the workload.

Operational limits and migration to ext4

ext3 is usually not selected for a new deployment when ext4 is available because ext4 provides a newer feature generation, better scalability, and performance-oriented improvements. ext3 can still be suitable for an existing installed system, a legacy boot environment, a compatibility requirement, or a constrained upgrade plan where changing the storage stack adds unacceptable risk.

Changing file system types is not normally a simple in-place switch. A safe migration commonly involves a verified backup, creating or preparing the destination, restoring data, and validating permissions, ownership, labels, UUIDs, services, and mount points. A supported conversion path may exist in some environments, but it must be validated for the exact kernel and tools before use.

1. Document current mounts, labels, UUIDs, boot dependencies, and /etc/fstab.
2. Create and verify backups before changing storage.
3. Confirm compatibility of the kernel, boot loader, initramfs, and recovery environment.
4. Plan downtime and test the migration procedure.
5. Keep a rollback plan, including the original storage or a verified restore path.
6. After migration, test booting, mounting, permissions, services, and recovery procedures.

What journaling does not protect

Journaling improves crash consistency; it is not a backup mechanism. It does not protect against accidental deletion, ransomware, a failed device, faulty hardware that writes corrupt data, or loss of the entire storage device. Use verified backups, more than one recovery copy where appropriate, and storage health monitoring as complementary protections.

Practical workflow

Identify an existing ext3 data volume

lsblk -f
sudo blkid
findmnt -t ext3
df -Th

Match the device, type, label, UUID, mount point, and options before performing any operation.

Format and mount an unused partition

sudo umount /dev/sdb1
sudo mkfs.ext3 -L archive /dev/sdb1
sudo blkid /dev/sdb1
sudo mkdir -p /mnt/archive
sudo mount -t ext3 /dev/sdb1 /mnt/archive
findmnt /mnt/archive

Every step assumes that /dev/sdb1 was independently verified as the intended partition.

Prepare a system for migration

• Record lsblk -f, blkid, findmnt, and relevant fstab entries.
• Verify backups by restoring representative files.
• Validate boot and recovery dependencies.
• Schedule downtime and test the restore or conversion path before the change.

Exam-relevant summary

• ext3 is the third extended Linux file system and is based on ext2.
• Its primary ext2 improvement is journaling.
• Journal replay restores file system consistency after an unclean shutdown, but does not guarantee all recent application data.
• journal journals data and metadata; ordered journals metadata while ordering data first; writeback provides weaker data ordering.
• An inode stores metadata and data references; a directory entry stores the file name-to-inode mapping.
• UUIDs and LABELs are generally preferable to volatile device names in /etc/fstab.
• Run e2fsck or fsck.ext3 on an unmounted file system, and treat automatic repair as potentially destructive.
• ext4 is generally preferred for new deployments, while ext3 remains useful for legacy compatibility.
• Journaling is not a substitute for backups.

For broader Linux storage and command-line foundations, see Linux, Determine File Type, and Show The Full Path Of Shell Commands.