VMware ESXi and vSphere Cluster Management

ext4 File System: Features, Architecture, and Linux Administration

Learn how ext4 works, how it compares with ext2 and ext3, and how to create, mount, inspect, tune, repair, and expand ext4 file systems safely.

ext4, short for the Fourth Extended File System, is a journaling file system for Linux. It belongs to the ext family and is the successor to ext3. A file system organizes files, directories, metadata, free space, ownership, permissions, and other structures on a storage device.

Linux distributions commonly use ext4 for operating-system installations, home directories, application data, and general-purpose data volumes. This lesson covers both the design of ext4 and the commands used to administer it.

ext2, ext3, and ext4

Each member of the ext family stores files using related concepts such as inodes, directories, blocks, and superblocks. The major differences are journaling, allocation methods, scalability, and feature flags.

ext4 can generally mount ext2 and ext3 file systems because it retains compatibility with much of their on-disk design. However, enabling ext4-specific features changes compatibility. An older kernel or utility may reject a volume, mount it read-only, or fail to understand its metadata.

Before converting or enabling features on an existing volume, make and test a backup. Verify that the target kernel, boot environment, rescue media, and e2fsprogs version support the resulting feature set. A newly created ext4 file system can also have a different layout and feature profile from an ext3 volume converted in place.

Journaling and crash recovery

Journaling records intended file-system changes in a journal before, or while, those changes are applied to their normal locations. After a crash or power loss, the system can replay or discard incomplete journal transactions instead of discovering every metadata operation from scratch.

Journaling primarily protects file-system structure and metadata. It does not guarantee that recently written file contents reached stable storage, and it does not protect against accidental deletion, application bugs, malware, failing hardware, or corruption that is copied into backups.

ext4 architecture

Core structures

• An inode stores metadata about a file, including ownership, permissions, timestamps, size, and references to its data. The filename is normally stored in a directory entry, not in the inode.
• A directory entry maps a name to an inode number. Directories are themselves special files containing these mappings.
• A block is a fixed-size unit of storage used for metadata or file data.
• A block group is a subdivision containing related metadata structures and data blocks. Grouping related information can reduce access distances.
• The superblock describes the file system layout, state, block size, inode size, feature flags, UUID, and other global parameters. Backup copies may exist in selected block groups.
• The journal contains transactions used for crash recovery.

Extents and allocation

An extent describes a contiguous range of blocks belonging to a file. Instead of recording every block separately, ext4 can represent a large contiguous file region with a compact extent record. This is especially efficient for large files.

Delayed allocation postpones physical block selection until data is flushed. The file system can then see more of the pending write and make a better placement decision. Multiblock allocation lets the allocator reserve multiple blocks in one operation. Together, these techniques can reduce fragmentation and improve sequential-write performance.

These optimizations mean that free-space figures and physical placement are not always intuitive while applications still have data cached. A clean shutdown and normal writeback allow pending allocations to settle.

Additional features

Persistent preallocation deserves special attention. For example:

sudo fallocate -l 1G /mnt/data/reserved.img

This reserves one gibibyte of file-system space for the file. It does not mean that an application has written one gibibyte of meaningful initialized data. Sparse files, apparent size, allocated blocks, and actual content are separate concepts.

Capacity and naming limits

Creating and mounting an ext4 volume

Formatting is destructive. The following example uses /dev/sdXN as a placeholder; replace it only after confirming the real partition with device inventory tools. Never assume that a device name identifies the intended disk.

1. Identify the target block device or partition.
2. Create the file system and optionally assign a label.
3. Discover its UUID.
4. Create a mount point.
5. Mount it temporarily and verify type, capacity, and options.
6. Add a UUID-based entry to /etc/fstab only after testing.

lsblk -f
sudo mkfs.ext4 -L data /dev/sdXN
blkid /dev/sdXN
sudo mkdir -p /mnt/data
sudo mount /dev/sdXN /mnt/data
findmnt -t ext4
df -hT /mnt/data

Use the actual confirmed partition in the formatting command. mkfs.ext4 destroys existing file-system structures and normally makes existing data inaccessible.

A temporary mount lasts until unmounting or rebooting. For a persistent mount, obtain the UUID with blkid and add an entry such as this to /etc/fstab:

UUID=<uuid> /mnt/data ext4 defaults 0 2

The final fields request the normal mount options, disable legacy dump processing, and schedule the file system for the usual fsck pass ordering. Ensure the directory exists, then validate without rebooting:

sudo mkdir -p /mnt/data
sudo mount -a
findmnt /mnt/data

UUIDs are generally more stable than names such as /dev/sda1, which can change after hardware or boot-order changes. PARTUUID can also be useful when referring to a partition independently of its file-system contents.

Mount choices

Inspection and monitoring

The e2fsprogs suite provides the main ext-family administration tools.

Useful inspection commands include:

sudo tune2fs -l /dev/sdXN
sudo dumpe2fs -h /dev/sdXN
findmnt -t ext4
df -hT
df -ih

The superblock output shows the UUID, block size, inode information, journal details, feature flags, reserved-block percentage, mount count, and time-based check settings.

Checks, schedules, and reserved blocks

e2fsck checks consistency and can repair selected problems. A non-root test volume should normally be unmounted first:

sudo umount /mnt/data
sudo e2fsck -fn /dev/sdXN

The -n option answers no to repairs, making this a review rather than a repair operation. A real repair requires a suitable backup, an unmounted file system, and a maintenance plan. Root file systems are commonly checked from recovery media or an environment where they are not mounted read-write.

ext4 can be scheduled for checks based on mount count and elapsed time. Inspect these settings with:

sudo tune2fs -l /dev/sdXN | grep -E 'Mount count|Maximum mount count|Check interval|Next check'

Administrators can adjust selected values with tune2fs, for example:

sudo tune2fs -c 30 -i 6m /dev/sdXN

Use distribution policy and operational evidence when changing schedules. A journal does not make consistency checks permanently unnecessary.

Reserved blocks are capacity held primarily for privileged processes and file-system health. On a system volume, they can preserve room for logging, administration, and root processes when ordinary users fill the disk. Inspect them with tune2fs -l; changing the percentage should account for whether the volume is a system disk or a large data volume.

Growing and shrinking ext4

Ext4 can usually grow online when the underlying block device, partition, or logical volume has already been enlarged and the kernel supports the operation. The conceptual order is:

1. Expand the physical storage, partition, or logical volume.
2. Confirm that the kernel sees the new block-device size.
3. Grow the ext4 file system.
4. Verify the result with df and inspection tools.

sudo resize2fs /dev/sdXN
df -hT /mount/point

The exact partition or LVM steps depend on the storage layer. Shrinking is different: it requires an offline workflow, a file-system check, reducing the file system first, and then reducing the underlying container. Reversing that order can destroy data. Back up and rehearse the procedure before shrinking.

Performance and reliability choices

Extents reduce metadata overhead for contiguous files. Delayed and multiblock allocation improve placement decisions, while indexed directories make large-directory lookups practical. These features are general improvements, not guarantees that every workload will be fast.

• Servers: Keep barriers and sensible journaling defaults. Monitor free blocks, inodes, latency, and recovery requirements.
• Desktops: Default ext4 settings are usually an effective balance of convenience, performance, and durability.
• Removable media: Consider portability, clean unmounting, power-loss exposure, and compatibility with the systems that must read the device.
• Virtual machines: Avoid stacking aggressive write-cache settings without understanding guarantees from the guest, host, hypervisor, and storage device.
• Database-like workloads: Follow the database vendor's durability guidance. Do not weaken barriers or journal behavior merely because benchmark throughput increases.

Fragmentation is usually less severe on a healthy ext4 volume with adequate free space than on older file systems, but it can occur with nearly full volumes, repeated updates, and highly fragmented large files. Measure before acting. Defragmentation may be considered for a demonstrably fragmented workload, but it is not routine maintenance and requires free space, backups, and an application-aware plan.

For SSDs, TRIM tells the device which blocks are no longer in use. Periodic trimming with a system timer is often a good default:

sudo fstrim -av

The discard mount option performs discard operations as blocks are freed. It can be appropriate for some devices, but periodic fstrim may avoid continuous discard overhead. Confirm that the device, hypervisor, and storage path support discard correctly.

Feature flags and compatibility

Ext4 feature flags describe on-disk capabilities. Conceptually, features fall into three groups:

• Compatible: An older implementation can generally continue to use the file system while ignoring the feature.
• Read-only compatible: An older implementation may be able to read the volume but must not write using an unsupported feature.
• Incompatible: An older implementation must not mount the volume because it cannot safely interpret its layout.

Inspect features with:

sudo tune2fs -l /dev/sdXN | grep 'Filesystem features'

Kernel and e2fsprogs support must be considered together. A rescue image with an old kernel can be unable to mount a volume created by a newer system. Do not remove or alter feature flags as an improvised compatibility fix.

Migration planning

A safe migration from ext2, ext3, or another file system is an operational project:

1. Make a complete backup and test that selected files can be restored.
2. Record current capacity, inode use, permissions, ACLs, extended attributes, labels, UUIDs, mount options, and application requirements.
3. Confirm kernel, bootloader, rescue-media, and e2fsprogs compatibility.
4. Plan downtime or an application-consistent copy procedure.
5. Create a new ext4 file system and restore data when a clean layout and full feature set are desired, or use a documented conversion procedure when appropriate.
6. Verify checksums, ownership, permissions, ACLs, extended attributes, services, boot configuration, and monitoring.
7. Retain rollback media and the old copy until the new deployment has been accepted.

Converting ext3 in place may preserve the existing allocation history and inode layout. It does not automatically provide every advantage of a newly created ext4 volume, so choose between conversion and recreation based on downtime, capacity, compatibility, and restore requirements.

Troubleshooting common problems

Boot-time mount failure

• Check the /etc/fstab syntax and confirm that the mount directory exists.
• Verify the UUID with blkid.
• Run sudo mount -a after correction, before rebooting.
• Review system logs for the precise error.

Device name changed

Use lsblk -f or blkid to identify the volume, then use its UUID or a suitable PARTUUID in persistent configuration instead of relying on a volatile /dev/sdX name.

Errors after an unclean shutdown

Determine whether the volume is mounted, preserve relevant logs, and unmount it or use recovery media. Begin with an appropriate non-destructive check when possible. If repair cannot recover required data, restore from a known-good backup.

Free space appears inconsistent

Inspect reserved blocks, inode usage with df -i, deleted-but-open files, snapshots, and application data. Free bytes do not imply free inodes, and reserved capacity may not be available to ordinary users.

An older kernel cannot mount the volume

Inspect ext4 feature flags and verify kernel and e2fsprogs support. Do not disable features without a tested backup and a compatibility plan.

Expansion did not increase usable space

Confirm that the disk, partition, or logical volume was enlarged, confirm that the kernel sees the new size, run the appropriate resize2fs grow operation, and verify with df.

Exam-relevant summary

• ext2 has no journal; ext3 adds journaling; ext4 adds extents, improved allocation, scalability, and additional integrity features.
• An inode stores file metadata and data references; a directory entry maps a name to an inode.
• A journal improves recovery of file-system structure but is not a backup.
• Extents describe ranges of contiguous blocks.
• Delayed allocation postpones block selection; multiblock allocation reserves larger regions efficiently.
• Filename length and complete path length are different limits, and filename limits count bytes.
• UUID-based /etc/fstab entries are more stable than ordinary device names.
• Run file-system repair on an unmounted volume whenever possible.
• Ext4 can grow after its underlying storage grows; shrinking requires an offline, carefully ordered procedure.
• Feature flags determine compatibility with older kernels and utilities.

For related study, see the ext4 file system guide.