VMware ESXi and vSphere Cluster Management

ext3fs: The Linux Third Extended File System

Learn how ext3fs extends ext2 with journaling, how journal replay works, and how to create, mount, inspect, check, maintain, and compare ext3 volumes.

ext3, also called ext3fs, is the Linux Third Extended File System. It is based on ext2 and adds a journal so the file system can recover more quickly and reliably after an unclean shutdown. ext3 was historically a common default file system for Linux distributions. ext4 largely replaced it for new installations, but ext3 remains important when maintaining older systems or preserving compatibility.

This lesson covers ext3 architecture, journaling modes, ext2 compatibility, capacity limits, administration commands, recovery, and the practical differences between ext2, ext3, and ext4.

What ext3 adds to ext2

ext2 is the predecessor of ext3. Both use concepts such as superblocks, inode tables, directories, and data blocks. The major ext3 addition is journaling: recording selected file system updates in an on-file-system log before applying them to their normal locations.

Without journaling, a power failure can interrupt a multi-step update. For example, a directory entry might be written while an inode allocation update is still pending. The resulting metadata can disagree about which blocks or inodes are in use. ext3 uses its journal to make recovery from this type of interruption faster and more predictable.

Journaling does not make data indestructible. It is not a backup and does not protect against accidental deletion, a device failure, corruption in a valid completed write, theft, fire, or a disaster affecting the storage system.

Core ext3 architecture

An ext3 file system is created on a block device, such as a disk partition or logical volume. The file system divides that storage into fixed-size blocks and organizes those blocks with several kinds of metadata.

• Superblock: Core information describing the file system size, layout, state, block size, features, and other parameters. Backup superblocks may exist in other locations.
• Inode tables: An inode is a data structure containing metadata about a file or directory, including ownership, permissions, timestamps, size, and references to data blocks. The inode does not normally contain the file name.
• Directories: Directories map names to inode numbers. A file name limit is therefore different from a complete pathname limit.
• Data blocks: These hold the contents of regular files and, where appropriate, directory contents.
• Journal: An area inside the file system used to record transactions involving metadata and, depending on the selected mode, file data.

A simplified operation might update a file's inode, allocate a new data block, and add a name to a directory. The journal records the relevant transaction. After the transaction is safely committed, the normal metadata and data locations are updated according to the journaling mode.

Journal replay

An unclean shutdown is caused by power loss, a kernel crash, a forced reset, or another event that prevents normal unmounting. During the next mount, ext3 can perform journal replay: it processes completed or recoverable journal transactions and restores consistent file system metadata.

Replay is generally much faster than examining every block of a large non-journaled file system. It improves consistency recovery, but it cannot reconstruct data that was never committed, repair a failing disk, or undo a logically valid operation such as deleting the wrong file.

ext3 journaling modes

ext3 supports three principal data journaling modes. The mode affects what is recorded, the ordering of writes, durability behavior, and performance overhead.

The journal improves recovery speed and consistency, but it introduces write overhead. A stronger mode may improve recovery expectations while reducing performance. Test any change with representative workloads rather than assuming that the strongest mode is always best.

ext2 compatibility and conversion

ext3 was designed from the ext2 foundation. At a design level, an ext3 volume can be treated similarly to ext2 when its journal is absent or deliberately ignored under suitable conditions. This relationship made migration practical, but it does not mean every ext2, ext3, and ext4 feature combination is interchangeable across all kernels, boot environments, and utilities.

A historical migration path was to add a journal to an existing ext2 file system. The operation should be planned carefully:

1. Make and verify a current backup.
2. Ensure the file system is unmounted. Do not convert an actively mounted file system.
3. Use appropriate ext-family tooling to add the journal.
4. Update persistent mount configuration if necessary.
5. Mount the volume and verify its type, UUID, label, and contents.

sudo tune2fs -j /dev/sdb1

The example assumes that /dev/sdb1 has been verified and is unmounted. Removing or disabling journaling can permit ext2-style access, but this should be deliberate, backed up, and performed with tooling appropriate to the system. Kernel and utility support must be checked before changing legacy volumes.

Capacity and naming limits

These are commonly cited ext3 limits, not guarantees for every environment. Check the kernel, e2fsprogs version, architecture, block size, and other configuration details before planning a volume near a boundary.

Creating an ext3 file system

First identify disks and partitions:

lsblk -f
sudo blkid
findmnt

After confirming that the target is the intended unused partition, create the file system and assign a descriptive label:

sudo mkfs.ext3 -L legacydata /dev/sdb1

The equivalent form is:

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

Retrieve the new UUID and inspect the result:

sudo blkid /dev/sdb1
lsblk -f /dev/sdb

A label is a human-readable name. A UUID is a file-system identifier generated for the volume. UUIDs are commonly preferred in persistent configuration because device names can change when disks are added, removed, or detected in a different order.

Mounting ext3 temporarily

Mounting attaches a file system to a directory in the Linux directory tree. Create a mount point and mount the verified device:

sudo mkdir -p /mnt/legacydata
sudo mount -t ext3 /dev/sdb1 /mnt/legacydata
findmnt /mnt/legacydata
df -hT /mnt/legacydata

The -t ext3 option requests the file system type. Linux can often detect the type automatically, but stating it explicitly can make administration clearer on legacy systems. findmnt shows the source, target, type, and active options. df -hT shows capacity and file system type.

Persistent mounting with /etc/fstab

/etc/fstab defines file systems that should be mounted automatically. Use the UUID returned by blkid:

UUID=<filesystem-uuid> /srv/legacydata ext3 defaults 0 2

After creating the mount directory and editing the file, validate the entry before rebooting:

sudo mkdir -p /srv/legacydata
sudo mount -a
findmnt /srv/legacydata

The final two numeric fields traditionally control dump handling and file-system check order. The value 2 commonly places a non-root file system in the normal check sequence. Follow the conventions of the operating system managing the volume.

Useful mount options

Journaling mode can be selected in the fourth field of /etc/fstab or supplied temporarily with mount -o:

sudo mount -o data=ordered /dev/sdb1 /mnt/legacydata
sudo mount -o data=journal /dev/sdb1 /mnt/legacydata
sudo mount -o data=writeback /dev/sdb1 /mnt/legacydata

For many general-purpose ext3 systems, data=ordered is the balanced choice. data=journal adds data journaling overhead, while data=writeback has weaker data ordering and therefore needs careful workload evaluation.

noatime prevents routine access-time updates when files are read. This can reduce metadata writes and may help read-heavy workloads, but applications that depend on access times may behave differently. Related options such as relatime reduce unnecessary updates while preserving more access-time information; availability and behavior should be confirmed on the target kernel.

Inspection and verification

Checking and repairing ext3

e2fsck is the ext-family consistency checker. The generic fsck command may select an appropriate checker, but using the ext-specific tool makes the intended operation explicit.

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

The -f option requests a full check even when the file system appears clean. Review proposed repairs and ensure backups exist before accepting changes. A mounted read-write file system must not normally be checked or repaired because active changes can invalidate the checker’s view.

For a root file system, use rescue mode, recovery mode, or offline maintenance media. Do not attempt ordinary repair against the live mounted root volume.

Scheduled checks

ext-family file systems can have policies based on mount count or elapsed time. When a threshold is reached, the system schedules a consistency check even if the previous shutdown was clean. tune2fs -l displays relevant metadata, including check intervals and mount-count information.

sudo tune2fs -l /dev/sdb1

Scheduled checks are a maintenance policy, not a substitute for monitoring or backups. Administrators should balance check duration against the need to detect latent inconsistencies.

Recovery after an unclean shutdown

The normal first response is to allow the system to mount the volume and replay its journal. After recovery, inspect the mount status and system logs for I/O errors, repeated recovery messages, or indications of broader storage failure.

1. Allow normal mount-time journal replay to complete.
2. Verify the mount with findmnt and inspect capacity with df -hT.
3. Review kernel and system logs for disk errors or repeated journal failures.
4. If mounting fails or corruption is reported, unmount the volume and perform an offline e2fsck check according to the maintenance procedure.

If the journal cannot resolve inconsistencies, an offline check may find and repair metadata problems. Stop and investigate persistent I/O errors: repeated file-system repairs can be a symptom of failing storage rather than the root problem.

Converting ext2 to ext3

Adding a journal was a useful historical way to migrate ext2 volumes without recreating them. The target must be unmounted and backed up:

sudo umount /dev/sdb1
sudo tune2fs -j /dev/sdb1
sudo blkid /dev/sdb1

Update the relevant /etc/fstab entry to use ext3 if required, then mount and verify:

sudo mount -a
findmnt /srv/legacydata

Do not assume that a volume with ext3-compatible ancestry can use every ext4 feature. Feature flags, kernel support, boot tooling, and e2fsprogs versions determine compatibility. Test the complete migration and recovery process before changing production storage.

ext2, ext3, and ext4 compared

Extents are a way of describing ranges of contiguous blocks efficiently. ext4 also introduced other improvements intended to help large volumes, large files, allocation efficiency, and performance. The exact limits depend on block size, kernel, tools, and enabled features.

Choosing ext3 today

ext3 is generally not the preferred choice for a new Linux installation because ext4 offers newer scalability and performance-oriented capabilities and is more commonly supported as the modern extended file system. ext3 can still be reasonable when an older kernel, boot environment, appliance, application, or recovery process requires it.

• Retain ext3 when compatibility with a legacy system is the primary requirement and its capacity is sufficient.
• Prefer ext4 for most new general-purpose Linux deployments after confirming application and kernel support.
• Consider workload-specific file systems when requirements include very large storage, special snapshot behavior, or different performance characteristics.

Fragmentation and allocation performance can become concerns as volumes fill, files change frequently, or workloads use many small updates. Newer file systems generally provide improvements in allocation and scalability, but no file system removes the need for capacity planning, monitoring, and workload testing.

Troubleshooting common problems

Recovery is reported after a power interruption

Allow journal replay to complete. Then inspect logs and mount status. If the volume will not mount or corruption is reported, unmount it and run an offline e2fsck check. Look for storage errors if recovery messages repeat.

An /etc/fstab entry fails

Compare the configured UUID with sudo blkid, confirm the file-system type and mount point, create the directory if needed, and run sudo mount -a before rebooting.

sudo blkid
sudo mkdir -p /srv/legacydata
sudo mount -a
findmnt /srv/legacydata

A format command targeted the wrong device

Stop write activity immediately. Verify disks using lsblk -f, sizes, labels, UUIDs, and mount points. Restore from backups or use approved recovery procedures. Prevention is critical: never format an assumed device name without verifying it.

e2fsck says the file system is mounted

Unmount the target before checking it. If it is the active root file system, boot into rescue or recovery mode or use offline maintenance media.

Performance or durability changed after changing journal options

Confirm active options with findmnt. Compare the selected mode with the intended workload, return to the approved mode if necessary, and benchmark recovery behavior in a non-production environment before making the setting permanent.

Operational safeguards

• Keep tested backups; journal replay is not backup and restore.
• Use safe shutdown procedures whenever possible.
• Monitor device health, capacity, inode usage, and system logs.
• Use RAID or other storage redundancy where it fits the failure model, but remember that redundancy does not replace backups.
• Test conversion, fsck, journal recovery, and restoration procedures before applying them to production data.
• Verify device identity before every destructive command.

Command summary

# Identify devices and file-system identifiers
lsblk -f
sudo blkid
findmnt

# Create an ext3 file system — verify the target first
sudo mkfs.ext3 -L legacydata /dev/sdb1

# Mount temporarily
sudo mkdir -p /mnt/legacydata
sudo mount -t ext3 /dev/sdb1 /mnt/legacydata
findmnt /mnt/legacydata

# Check an unmounted volume
sudo umount /dev/sdb1
sudo e2fsck -f /dev/sdb1

# Inspect settings
sudo tune2fs -l /dev/sdb1

# Add a journal to an unmounted, backed-up ext2 volume
sudo tune2fs -j /dev/sdb1

# Validate /etc/fstab
sudo mount -a

For related material on this subject, see ext3fs.